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ABSTRACT 


The  premise  of  this  thesis  is  that  many  software 
application  systems  perform  similar  functions  on  a  data 
object  and  contain  a  significant  operational  Intersection. 
An  integrated  Apolicatlon  Software  System  (IASS)  Integrates 
the  capabilities  of  the  applications  into  one  system.  The 
purpose  of  this  thesis  Is  to  evaluate  the  utility  of  the 
relational  database  model  to  conceptually  Integrate  the  text 
processing,  relational  database  management,  form  generating, 
electronic  mail,  and  electronic  modeling  applications. 

The  conclusion  of  this  study  is  that  the  relational 
database  model  can  conceptually  support  the  data 
representation  and  manipulation  requirements  of  each 
application  considered.  Furthermore,  the  Integrated  system 
has  potential  capabilities  that  are  not  available  in  the 
non-lntegrated  set  of  applications.^ 
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BIBLIOGRAPHY 


INITIAL  DISTRIBUTION  LIST 


I.  introduction 


A.  APPLICATION  SOFTWARE  PROBLEM 

The  utilization  of  computers  in  many  areas#  such  as 
personal  computing  or  office  and  manufacturing  automation# 
is  rapidly  expanding.  No  longer  is  tnelr  use  oelng 
relegated  to  support  personnel#  but  is  spreading  into  tne 
ranks  of  lower  and  middle  level  management.  The  majority  of 
such  users  are  non-computer  professionals  wno  are  coming  to 
depend  on  the  computer  to  provide  support  to  accomplish 
their  primary  responsibilities. 

Over  the  past  years#  numerous  software  packaoes  have 
been  made  available  to  support  a  broad  spectrum  of  users  in 
varying  environments.  Capabilities  such  as  word  processing# 
database  management#  modeling#  form  generation#  and 
electronic  mall  have  become  essential.  The  purpose  of 
introducing  the  computer  into  an  organization  is  to  increase 
effectiveness  and  efficiency.  While  the  performance  of  each 
support  package  is  individually  satisfactory#  tne  manner  in 
which  they  are  presented  to  the  user  as  a  group  is  not.  As 
illustrated  in  Figure  1.1#  each  support  system  is  typically 
disjoint  from  all  others#  and  the  user  is  presented  with 
different  models#  command  vocabularies#  and  operating 
instructions.  This  non-lntegrated  combination  of 
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application  software  requires  a  special  effort  on  the  part 
of  the  user  to  learn  a  new  system  and  remember  it  alonq  with 
the  other  systems  that  are  used.  For  instance,  one  simple 
task  ean  be  invoked  in  a  different  way  in  each  system. 


Flqure  1,1  -  Disjoint  Support  Systems. 


a,  THE  IASS  OBJECTIVES 

wnat  Is  needed  to  Increase  productivity  is  an  integrated 
system  that  combines  the  capabilities  of  the  applications 
and  presents  tne  user  with  a  single,  yet  easy,  conceptual 
data  model  and  vocabulary  set.  It  is  such  a  system  that  is 
called  an  Integrated  Application  Software  System  (IASS).  The 
objectives  of  such  a  system  are: 

(1)  Ensure  a  high  degree  of  user  friendliness  and 
emphasize  simplicity. 

(2)  Minimize  the  initial  and  acquired  user  skill  level 
necessary  to  use  the  system. 

(3)  Minimize  the  learning  time  required  to  use  the 

system. 
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(4)  Present  a  logical  distinction  between  each  of  the 
IASS'*  capabilities,  but  minimize  explicit  navigation 
between  them, 

(5)  Realize  the  largest  functional  intersection  of  the 
capabilities  of  each  included  application* 

(6)  Develop  a  minimum  set  of  primitive  commands. 

(7)  Minimize  the  dependence  on  programming  In  order  to 
use  the  system. 

(8)  Embody  the  notion  of  software  adaptivity  whereby 
the  user  ean  learn  a  new  application  oy  learning  only  a 
small  Increment  of  new  apollcatlon  specific  commands  and 
functions. 

(9)  Embody  the  notion  of  software  reusability.  New 
applications  can  oe  implemented  by  adding  a  small  Increment 
of  functions  and  commands  which  can  be  expressed  in  terms  of 
existing  IASS  operations, 

while  the  IASS  cannot  be  expected  to  completely 
Integrate  tne  features  of  each  support  package,  it  can 
strive  to  maximize  the  intersection  between  them.  Figure  1.2 
shows  a  simple  illustration  of  an  IASS  In  a  Venn  Diagram. 


Figure  1.2  -  IASS  Intersection 


The  purpose  of  this  thesis  is  to  determine  the  utility  of 
the  relational  database  model  as  the  xernei  of  the  IASS. 

C.  IASS  APPLICATIONS 

Five  common  software  applications  were  selected  to  be 
integrated: 

(1)  Text  Processor 

(2)  Relational  Database  Management  System 

(3)  electronic  Spread  Sheet 

(4)  forms  Generator 

(5)  Electronic  Mail 

As  a  non-integrated  collection  of  application  software, 
each  is  implemented  to  accomplish  a  predefined  set  of 
operations  on  a  specific  tile  type.  Data  in  a  file  is  not 
directly  sharable  between  applications  and  neither  are  the 
commands  to  manipulate  the  data.  Command  vocabularies  are 
usually  "baroaue"  in  tnat  most  of  the  operators  are  intended 
to  exist  as  a  matter  of  convenience  to  the  user.  However, 
too  often  it  is  a  very  small  percentage  of  the  overall 
vocabulary  that  is  used  most  of  the  time,  users  usually 
learn  a  subset  of  the  vocabulary  necessary  to  accomplish  the 
essential  functions  of  the  application,  and  disregard  the 
rest.  It  is  the  intersection  of  functions  and  vocabularies 
that  the  IASS  subsumes  and  maxes  the  common  system  for  all 
included  applications . 
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Commercially  available  software  application  packages 
ware  reviewed  to  determine  the  nature  of  the  logical  file 
types  and  the  essential  functions.  A  detailed  description 


of  each  of  the  application  packages  Is  included  in 
Appendices  A  through  I. 
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II.  IASS  DATA  OBJECT 


A.  THE  TABLE 

The  logical  file  of  any  aoplieacion  system  contains  data 
which  is  used  by  a  specific  set  of  application  proorams. 
The  Key  to  achieving  an  Integrateo  Application  Software 
System  (IASS)  which  can  support  each  logical  file  type  is  to 
map  each  into  one  data  object.  The  data  object  chosen  for 
tne  IASS  is  the  table  since  it  is  a  natural  method  of 
organizing  data  and  is  an  easily  understood  object.  Each 
column  in  the  table  represents  one  attribute  of  the  file  and 
each  row  represents  an  unique  occurrence.  The  taples 
include  columns  whicn  represent  Key  values  to  uniquely 
identify  eacn  row.  Any  datum  in  a  table  can  oe  accessed  by 
specifying  th«  name  of  the  table,  the  value  of  the  Key,  and 
the  name  of  the  attribute  containing  the  datum.  In  this 
thesis,  rows  will  win  also  be  referred  to  as  tuples  or 
lines  and  columns  as  attributes  or  fields.  A  complete 
description  of  the  table  is  given  in  Martin  [Ref.  i). 

This  chapter  describes  tne  preliminary  design  of  a  set 
of  tables  which  can  support  the  data  requirements  of  the 
IASS  applications. 
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B.  IASS  TABLES 

In  the  IASS  each  application  Is  a  logical  database 
consisting  of!  a  set  of  tables.  There  are  three  general 
classes  of  tables,  data  table,  application  directory,  and 
data  table  schema.  The  data  table  represents  the  logical 
file  of  an  application.  The  data  tables  are  typed  according 
to  their  primary  use  as,  text,  form  text,  database,  spread 
sheet,  and  mail.  Data  table  typing  is  done  only  to 
logically  organize  data  taoles  whicn  are  used  primarily  by 
the  same  application  programs.  The  IASS  does  not  support 
strong  data  table  typing.  Being  able  to  combine  taoles  of 
different  types  is  an  important  feature  of  the  IASS. 

The  abdication  directory  table  contains  descriptive  and 
definitional  data  aoout  the  data  tables  in  an  application  or 
logical  dataoase.  Each  row  in  the  application  directory 
table  describes  one  data  table  and  has  a  standard  schema. 
Figure  2.1.  10  Is  the  primary  Key  value  of  the  application 
directory  table.  NAME  is  the  unique  name  of  the  data  table. 
COLUMNS  Is  a  list  of  column  names  in  tne  data  table.  This 
list  Implicitly  defines  tne  schema  of  the  data  table. 
ACCESS  CONTROL  defines  the  access  privileges  of  various 
classes  of  system  users  to  the  taple,  including  read  and 
write  access  and  privileges  to  modify  tne  data  taole  schema. 
This  data  item  also  contains  information  concerning  which 
operations  are  allowed  on  the  data  taole.  For  instance,  it 
may  be  decided  that  one  dataoase  data  table  cannot  be  joined 
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nra* 


with  a  mall  data  table.  TABLE  POINTER  points  to  the  data 
table.  DESCRIPTION  Is  a  literal  description  of  the  table. 
VIRTUAL  indicates  whether  the  data  table  is  composed  from 
other  IASS  data  tables.  CONDITION  indicates  how  a  virtual 
table  Is  composed.  For  example.  If  the  virtual  data  table 
was  formed  by  a  join,  tnat  data  would  be  stored  in  the 
CONDITION  column  of  the  application  directory.  GLOBAL 
contains  all  the  recurring  Information  which  is  applicable 
to  a  data  table  as  a  whole,  such  as  formatting,  display  mode 
(e.g.  page  or  table),  access  patns.  etc.  For  each 
application,  tne  schema  of  the  application  directory  table 
can  be  augmented  as  required. 


nr 

NAME 

COLUMNS 

ACCESS 

TABLE 

virtual 

LL 

CONTROL 

pointer 

condition 

GLOBAL 

DES- 

CRIPTION 

Figure  2.1  -  Application  Directory  Table  Schema 


The  data  table  schema  table  contains  a  row  for  each 
column  In  the  data  tables.  The  schema  of  the  data  table 
schema  table  Figure  2.2.  is  the  same  in  each  application. 
ID  is  the  primary  Key  of  the  taole.  Each  column  in  the  a 
data  table  has  an  unique  name,  type  and  width  describe  tne 


IS 


data  type  associated  with  the  column  and  the  maximum  width 
of  the  data  entry. 


1  to 

NAME 

TYPE 

WIDTH 

SYNONYM 

■win 

ACCESS 

LI 

■HH 

CONTROL 

Figure  2.2  -  Data  Table  Schema  Table 


Data  typing  supports  the  data  integrity  function  of  the 
underlying  system.  SYNONYM  is  the  list  of  names  oy  which 
the  column  could  be  referred.  This  Information  is  used  to 
determine  relationships  that  exist  with  otner  data  tables, 
possibly  of  a  different  type  or  allows  the  same  column  to  be 
referred  to  oy  many  different  names  depending  on  the  context 
of  Its  use.  For  example.  In  a  personnel  data  table,  the 
column  name  may  be  PNAME.  This  column  could  be  referred  to 
as  PERSNAME,  name,  PERSON,  etc.  This  column  must  be  used 
with  caution.  Its  data  may  inadvertently  chanae  the  access 
privileges  of  a  user  to  a  data  item.  TABLE  is  the  data 
tables  the  column  occurs  In.  A  query  of  the  data  table 
schema  table  can  be  done  to  determine  the  names  of  the 
tables  the  column  is  In  to  avoid  searching  through  an  entire 
application  directory.  ACCESS  CONTROL  defines  the 
privileges  associated  with  eacn  column  for  a  elass  of  system 
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users  including  read  and  write  access  and  privileges  to 
modify  tne  column  definition. 

Figure  2.3  snows  the  relationships  between  the  tables 
that  exist  In  each  application. 


Application  Directory 


nr 

name 

COLUMNS 

ACCESS 

TABLE  | 

VIRTUAL 

LL 

CONTROL 

POINTER  | 

I - 

Data  Table  Schema 


CONDITION 

GLOBAL 

DES- 

1 

1 
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CRIPTION 

1 

t 

TABLE 

1 


ID 

NAME 

TYPE 

WIDTH 

SYNONYM 

TABLE 

ACCESS 

CONTROL 

I 

■ 

||  ■ 

n_ 

Figure  2,3  -  IASS  Table  Relationships 

This  figure  Indicates  that  each  row  in  the  application 
directory  table  is  connected  to  a  set  of  rows  in  the  data 
table  schema  table  and  a  data  table.  The  dotted  line  shows 
a  cross  reference  from  a  data  table  schema  table  row  to  a 
directory  table  row. 
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1.  Text  Processor  Tables 


a.  Text  Directory  Table 

The  text  directory  table  contains  a  row  for  each 
text  data  table.  The  directory,  Figure  2,4,  has  the 
standard  application  directory  schema.  Since  the  text  data 
tables  can  be  output  to  a  visual  medium,  each  data  table  has 
a  global  print  format.  This  data  is  stored  in  the  GLOBAL 
columns  or.  If  necessary,  in  a  table  accessed  via  tne  data 
in  the  GLOBAL  columns,  and  contains  the  page  length,  right 
and  left  margin,  top  and  bottom  margin,  number  of  lines  per 
page,  page  neader,  page  footer,  tab  spacing,  and  line 
spacing. 


j  id" 

NAME 

COLUMNS 

ACCESS 

TABLE 

VIRTUAL 

UL 

CONTROL 

POINTER 

CONDITION 


GLOBAL 


DES¬ 

CRIPTION 


Figure  2.4  -  Text  Directory  Table  Schema 


b.  Text  Data  Table  Scnema  Table 

The  text  data  table  schema  table.  Figure  2,5, 
contains  the  predefined  column  set,  ID  and  TEXT  LINE.  The 
10  is  the  primary  Key  of  the  text  data  table.  TEXT  LINE 
describes  the  TEXT  LINE  column  in  tne  text  data  table.  As 
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Figure  2.5  snows,  the  TEXT  LINE  can  bo  aliased  with  the  FORM 
LINE  column  in  a  form  text  data  table  or  tne  BODY  column  in 
a  mail  data  table. 


ID  NAME  TYPE  WIDTH  SYNONYM  TABLE  ACCESS 

CONTROL 


1 

10 

IN¬ 

TEGER 

NONE 

ALL 

read:  all 
write:  dba 
modify:  DBA 

2 

TEXT 

LINE 

CHAR 

FORM 

LINE, 

BODY 

ALL 

read:  all 
write:  all 
modify:  DBA 

Figure  2.S  -  Text  Data  Table  Schema  Table 


c.  Text  Data  Table 

The  text  data  table.  Figure  2.6.  Is  described 
by  tne  columns  and  DESCRIPTION  columns  in  tne  text  directory 
table.  It  contains  data  used  to  prepare  a  printed  document 
or  a  computer  program.  The  rows  In  a  text  table  are  sorted 
on  tne  ID  column.  Each  row  has  an  unique  ID  number  which 
corresponds  to  the  line  number  In  the  display.  Although  the 
user  can  refer  to  an  ID  numoer.  an  ID  number  cannot  oe 
directly  modified.  The  data  in  a  TEXT  LINE  is  unformatted, 
in  a  single  line  of  text,  there  are  two  Minds  of  data  that 
are  recognized,  the  character  string  to  be  printed  and 
special  combinations  of  characters  to  be  executed.  The 
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executable  characters  are  specific  to  a  text  processor 


application  program  (e.g.  text  formatter  or  compiler). 
Figure  2.6  shoes  the  two  Kinds  of  data.  Rows  1  and  2 
contain  literal  character  strings  to  be  printed.  Row  n 
contains  a  formatting  command  (page-break). 


ID  TEXT  LINE 


now  is  the  time 

hi 

LJ 

for  all  good  men  to 

•  M 

.oa  | 

Figure  2.6  -  Text  Data  Table 


2.  Oataoase  Tables 

a.  Database  Directory  Table 

The  database  directory  table  contains  a  row  for 
each  database  data  table.  The  database  directory  table. 
Figure  2.7,  nas  the  standard  application  directory  schema. 
The  GLOBAL  column  contains  data  descriolng  tne  display  mode 
or  printed  format. 
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CONTROL 

POINTER 

CONDITION 

GLOBAL 
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Figure  2.7  -  Database  Directory  Table  Schema 


20 


b.  Database  Data  Table  Schema  Table 

The  database  data  taDle  schema  table,  Figure 
2.8,  initially  contains  an  entry  only  £or  the  ZD  column. 
The  ID  is  a  Key  In  the  database  data  table.  As  database 
data  tables  are  defined,  entries  to  the  database  data  table 
schema  table  will  have  to  be  made. 


ID  NAME  TYPE  WIDTH  SYNONYM  TABLE  ACCESS 

CONTROL 


■ 

ID 

INTEGER 

NONE 

ALL 

readr  all 
write:  DBA 
modify:  DBA 

Figure  2.8  -  Database  Data  Table  Schema  Table 


c.  Database  Data  Table 

Each  database  data  table.  Figure  2.9,  represents 
one  entity,  and  is  descrloed  by  the  columns  and  DESCRIPTION 
column  in  the  database  directory  taole.  Tne  data  in  a 
aataoase  data  table  is  formatted.  Each  row  is  an  unique 
occurrence  of  the  entity.  Tne  columns  of  tne  database  data 
taole  are  the  attributes  of  the  entity.  ID  contains  the 
display  order  of  a  row.  This  ordering  does  not  imply  that 
there  is  a  canonical  ordering  of  the  entity.  Tne  ID  can  oe 
referred  to  out  cannot  be  directly  modified  by  the  user. 
The  other  columns  of  the  database  data  table  are  not 
predefined.  The  database  data  table  can  oe  directly  viewed 
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at  the  screen  by  the  user  or  printed,  but  may  be  reformatted 
based  on  the  data  In  the  GLOBAL  eolumn  if  necessary. 


TD  ATTR-1  ATTR-2  ATTR-n 


Figure  2,9  -  Database  Data  Table 


3.  Form  Generator  Tables 

a.  Form  Text  Directory  Table 

The  form  text  directory  table  has  the  standard 
applications  directory  schema,  Fioure  2.10.  because  the 
form  is  intended  to  be  orinted,  each  form  contains  a  Dtint 
format  ehich  is  defined  by  the  data  aoaregate  named  GLOBAL . 
This  data  aoqreaate  is  the  same  as  that  contained  in  the 
text  directory  table  previously  described. 


nr 

NAME 

COLUMNS 

ACCESS 

TABLE 

VIRTUAL 

LI 

CONTROL 

POINTER 

CONDITION 

GLOBAL 

nes- 

CRIPTIPN 

Figure  2.10  -  Form  Text  Directory  Table  schema 
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b.  Form  Text  Data  Table  Schema  Table 


The  form  text  data  table  schema  table,  Figure 
2.11  contains  the  predefined  column  set  ZD  and  FORM  lime. 
The  ZD  is  the  primary  key  of  the  form  text  data  table.  FORM 
LINE  describes  the  FORM  LINE  column  in  the  form  text  data 
table.  Figure  2.11  shows  that  the  FORM  LINE  column  can  be 
aliased  with  the  TEXT  LINE  column  in  a  text  data  taole  or 
the  BODY  column  in  mail  data  table. 


ID  NAME  TYPE  WIDTH  SYNONYM  TABLE  ACCESS 

CONTPOL 


1 

ID 

IN¬ 

TEGER 

m 

ALL 

read:  all 
write:  DBA 
modify:  DBA 

2 

FORM 

LINE 

CHAR 

TEXT 

LINE, 

BODY 

ALL 

reaa:  all 
write:  all 
modify:  DBA 

Figure  2.11  -  Form  Text  Data  Taole  Schema  Table 


c.  Form  Text  Data  Table 

A  form  is  a  repetitive  document  with  blanics  to 
be  filled  in.  A  form  can  be  represented  as  a  collection  of 
rows  contained  in  a  taole,  as  shown  in  Figure  2,12,  and  is 
described  by  the  COLUMNS  and  DESCRIPTION  columns  in  the  form 
text  directory  table. 


ID 

FORM  LINE 

T 

{NAME} 

"7 

{ADDRESS) 

3 

4 

Dear  <B. RELATION) 

S 

FORMl .TXT 

Figure  2.12  -  Form  Text  Table 


Each  row  of  the  table  is  sorted  on  tne  ID  and  corresponds  to 
the  same  row  in  the  form.  Although  the  user  can  reference 
an  ID  number.  It  cannot  be  directly  modified.  The  FORM 
LINE  column,  contains  unformatted  data,  in  addition  to 
literal  character  strings  which  are  printed.  Including 
horizontal  and  vertical  lines,  it  contains  a  special  set  of 
executable  data.  A  special  character  comoination  indicates 
whether  the  blanks  in  the  form  are  to  filled  in  by  the  user 
and  stored  in  a  table,  or  whether  the  blanks  are  to  De 
filled  in  from  a  table.  This  special  set  of  data  must  oe 
known  by  the  user  as  it  is  merely  inserted  as  a  combination 
of  characters  into  the  FORM  LINE  column.  The  view  of  tne 
form  at  design  and  modification  time  is  exactly  that  of  the 
form  data  table  although  it  may  be  reformatted  if  necessary. 

Figure  2.12  contains  an  example  of  the  data  in 
the  form  text  data  table.  The  data  in  tne  first  form  line 
indicates  that  the  printed  value  for  the  first  row  in  the 
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printed  form  is  to  be  retrieved  from  the  name  column  of  tne 
selected  row  of  the  associated  database  data  table.  Tne 
data  in  the  fourth  form  line  indicates  that  the  printed  form 
is  to  contain  the  literal  string  'Dear'  followed  oy  tne 
value  from  the  RELATION  column  of  taole  B  of  the  associated 
database  data  table.  The  information  In  row  4  also 
indicates  that  the  associated  taole  is  a  join  of  two  taoles 
each  containing  a  column  named  RELATION.  Row  5  indicates 
that  the  body  of  tne  form  is  a  text  data  table  named  FURMi. 

A  form  text  data  table  is  similar  to  a  text 
table.  They  differ  only  in  their  data  content  and  tne  way 
they  are  used.  The  data  in  the  form  t»xt  data  table  can  oe 
variables  wnose  values,  are  determined  at  print  time.  The 
variables  in  a  form  do  not  have  to  be  bound  to  a  named  data 
table  or  specific  row  in  a  data  table  and  tnerefore  can  be 
re-used  in  tne  same  or  in  many  different  applications, 

4.  Electronic  Mail  Tables 
a.  Mail  Directory  Table 


NAME 

COLUMNS 

ACCESS 

TABLE 

VIRTUAL 

LL 

CONTROL 

POINTER 

CONDITION 

GLOBAL 

HFS- 

CRIPTION 

Figure  2.13  -  Mall  Directory  Table  Schema 


The  mail  directory  table  contains  a  row  for  each 


mail  table.  The  standard  application  directory  schema  does 
not  have  to  be  modified  for  the  mail  application,  figure 
2.13.  The  GLOBAL  data  items  contain  the  data  to  determine 
ownership  of  tne  mall  data  table  and  any  other  applicable 
Information. 

o.  Mali  hata  Table  Schema  Table 


ID  NAME  TYPE  WIDTH  SYNONYM  TABLE  ACCESS 

CONTROL 


1 

ID 

INTE 

-GER 

NONE 

ALL 

read:  all 
write:  DBA 
modify:  DBA 

2 

FROM 

CHAR 

NONE 

ALL 

r*ad:  all 
write:  all 
modify;  DBA 

3 

TO 

CHAR 

NONE 

ALL 

^3^ 

1 

COPY  TO 

CHAR 

NONF 

ALL 

Bggg 

1 

OATS 

CHAR 

NONE 

ALL 

read:  all 
write:  all 
modify:  DBA 

1 

SOB  J 

CHAR 

SUB¬ 

JECT 

ALL 

read:  all 
write:  all 
modify:  DBA 

1 

BODY 

CHAR 

TEXT  LINE, 
FORM  LINE 

ALL 

reed:  all 
write:  all 
modify:  DBA 

Figure  2.M  -  Mall  Data  Table  Schema  Table 


The  mall  data  table  schema  table,  Flaure  2.14, 
contains  the  system  defined  columns  of  a  message.  The  ID  Is 
the  primary  Key  of  each  mall  table.  .  The  other  columns 
contain  the  data  to  denote  the  originator,  redolent*, 
subject  and  the  body  of  the  message.  Figure  2.14  snows  that 
the  BODY  can  be  synonymous  with  the  TEXT  LINE  of  a  text  data 
table  or  FOB*  LINE  of  a  form  text  data  table 
c.  Mail  Data  Table 


ID  FPOM  TO  COPY  TO  DATE  SUBJ  BODY 


l 

ME 

YOU 

THEM 

1/1 

MESSAGE 

2 

YOU 

ME 

THEM 

1/2 

MSG. TXT 

t 

* 

»  « 

a 

*  a 

ar 

E 

_ 

_ 

1 

Figure  2.15  •  *all  Data  Table 


Electronic  mall  Is  a  utility  which  facilitates 
the  excnanoe  of  textual  messages  between  system  users.  A 
mall  file  contains  a  set  of  messages.  The  message  consists 
of  data  items  which  are  read  by  the  recipients.  The  mall 
table.  Figure  2.15,  is  described  by  the  columns  and 
DE5CP IPTION  columns  in  the  mail  directory  table.  Each  row 
in  the  table  corresponds  to  one  message.  Each  message 
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contains  a  header  which  Is  comprised  of  the  FROM,  TO,  COPY 
TO,  DATE,  and  SUBJECT  of  the  messaqe.  The  BODY  column  can 
contain  the  entire  messaqe  or  the  name  ot  a  text  table.  For 
example,  Flqure  2.15  shows  that  messaqe  1  contains  the 
entire  messaqe  body.  Message  2  contains  the  name  of  a  text 
data  table  in  the  text  directory  table.  Tne  mail  table  can 
be  directly  viewed  by  the  user  as  a  summary  of  the  messages 
out  should  be  reformatted  to  read  or  edit  a  sinale  message. 

5 .  Electronic  Spread  Sheet  Tables 
a.  So read  Sheet  Directory  Table 

The  soread  sheet  directory  table  contains  a  row 
for  each  spread  sheet  data  taole.  Tne  standard  apoiicatior. 
directory  schema.  Figure  2. its,  is  used. 


ID 

NAME 

COLUMNS 

ACCESS 

TABLE 

VIRTUAL 

CONTROL 

POINTED 

CONDITION 

GLOBAL 

OFS- 

CRIPTIOU 

Fiaure  2.16  -  Soread  Sheet  Directory  Table  Schema 


The  GLOBAL  data  items  define  the  recalculation  order, 
default  format,  and  any  other  information  aooiicabie  to  tne 
referenced  spread  sheet  data  table. 


20 


b.  Spread  Sheet  Data  Table  Schema  Table 


The  spread  sheet  data  table  schema  table.  Figure 
2.17,  contains  the  predefined  columns  of  the  spread  sheet 
data  table.  ID  Is  the  primary  Key  of  the  spread  sheet  data 
table.  The  other  columns  contain  the  data  to  calculate  the 
value  of  an  entry  position  and  construct  the  user  view  of 
the  spread  sheet  data  table. 


ID  NAME  TYPE  WIDTH  SYNONYM  TABLE  ACCESS 

CONTROL 


1 

ID 

IN¬ 

TEGER 

NONE 

all 

read:  all 
write:  DBA 
modify:  DBA 

2 

X 

INDEX 

CHAP 

NONE 

ALL 

■ 
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INDEX 

IN¬ 

TEGER 

NONE 

ALL 

read:  all 
write:  all 
modify:  DBA 

■ 

FORMAT 

CHAR 

NONE 

ALL 

read:  all 
write:  all 
modify:  DBA 

5 

VALUE 

CHAR 

NONE 

ALL 

read:  all 
write:  all 
modify:  DBA 

6 

FUNC¬ 

TION 

CHAR 

NONE 

ALL 

Flnure  2.17  •  Spread  Sheet  Data  Table  Schema  Table 
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c.  Spread  Sheet  Data  Table 

A  spread  sheet  data  table  contains  the  formatted 
data  to  calculate  the  values  of  and  display  a  numerical 
model.  The  spread  sheet  data  table  Is  described  by  the 
COLUMNS  and  DESCRIPTION  columns  in  the  soread  sheet 
directory  table.  A  spread  sheet  data  table,  Figure  2. IS,  Is 
pointed  to  by  a  TABLE  POINTER  in  the  soread  sheet  directory 
table. 


ID  X  Y  FORMAT  VALUE  FUNCTION 


1 

A 

l 

INTEGER 

RIGHT 

3 
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T 

A 

2 

INTEGER 

RIGHT 

3 

5 

5 

n 

A 

3 

INTEGER 

10 

A 1  ♦  A2 

RIGHT 

3 

Figure  2.19  -  Spread  Sheet  Data  Table 


The  spread  sheet  data  table  can  be  considered  to  be  the 
tabular  representation  of  the  traditional  spread  sheet  view, 
Figure  2.19,  or,  conversely,  the  traditional  soread  sheet 
view  car  be  regarded  as  one  dlsoiay  mode  of  the  soread  sheet 
data  table.  Each  entry  position  In  the  view  is  defined  by 
one  row  in  the  spread  sheet  data  table. 
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A  B  C  0  E  F 

1  5 

2  5 

3  10 

Figure  2.19  -  spread  sheet  view 

The  ID  Is  the  display  order  of  the  spread  sheet 

data  table  but  does  not  provide  the  ordering  for  the  entry 

positions  In  the  spread  sheet  view.  The  x  and  Y  Index 

columns  represent  the  relative  Position  of  the  entry 
position  in  the  soread  sheet  view.  The  mapping  of  the  X  and 
Y  indices  to  the  display  is  contained  in  tne  GLOBAL  column 
of  tne  soread  sheet  directory  table.  The  format  column 
contains  the  data  describing  the  display  of  the  entry 
position,  A  numeric  value  of  an  entry  Position  can  be 
dismayed  as  an  integer,  floating  point,  or  dollar  and  cents 
number.  The  format  information  also  indicates  whether  the 
values  should  be  right  or  left  justified  and  the  width  of 
the  entry  position  in  the  display.  The  value  column 

contains  the  dlsplav  value  of  the  FUNCTION  column.  The 
function  column  contains  an  exoression  which  is  used  to 
determine  the  value  of  the  entry  position.  The  expression 
could  be  tne  typical  constant,  literal,  or  arithmetic  tvoes, 
or  could  be  a  database  query,  or  a  pointer  to  any  other  IASS 
data  table.  The  operands  of  an  expression  can  be  any 
constant  value  or  the  value  of  another  entry  oositlon  in  the 
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spread  sheet.  An  operand  value  can  also  be  an  arithmetic, 
trigonometric,  or  some  other  predefined  function,  which  can 
use  the  value  of  another  entry  position  as  a  parameter. 
Using  tne  value  of  another  entry  position  as  an  operand  In 
an  expression  Is  necessary  to  support  dynamic  modeling,  l.e, 
when  a  change  Is  made  to  one  entry  position,  It  Is 
immediately  refleeted  in  the  entire  spread  sheet  view.  As  a 
matter  of  fact,  the  freedom  to  define  value  of  one  entry 
position  In  terms  of  any  other  entry  position  resulted  in 
one  data  table  structure  end  it  also  prevented  us  from  using 
the  database  mteority  enforcement  mechanism  for  the  soread 
sheet  view. 
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III.  CONCEPTUAL  INTEGRATION 


A.  OVERVIEW 

The  main  design  objective  of  the  integrated  Application 
Software  System  (IASS)  Is  to  oresent  the  user  with  a  slnole 
conceptual  view  of  the  system  regardless  of  the  context  of 
its  use.  From  the  user's  perspective,  there  is  only  one  data 
object,  the  table.  As  was  indicated  in  Chapter  2,  depending 
on  the  level  of  experience  or  Intent  of  the  user,  a 
translation  may  be  required  to  reformat  a  data  table.  This 
translation  Is  from  table  to  table  and  therefore,  the  notion 
of  a  sinqle  data  object  Is  preserved. 

At  the  conceptual  level  of  each  application  there  Is  a 
common  set  of  table  operators  and  a  set  of  application 
specific  table  operators.  The  common  set  of  table  operators 
represents  the  transportable  Knowledge  of  the  system  as  the 
user  looicaliy  traverses  between  applications.  The  user  must 
learn  or  be  cognizant  of  only  the  application  specific 
operations  as  the  system  use  chenaes. 

By  functionally  cateqorlzlng  each  data  manipulation 
operations  on  the  logical  file  of  the  non-DBMS  applications, 
an  Intersection  can  be  deduced.  The  intersection  is 
comprised  of  operations  to  locate,  insert,  modify,  delete, 
copy,  and  move  data  In  a  file.  These  operations  can  be 
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Integrated  at  the  conceptual  level  by  a  set  of  six  basic 
IASS  primitive  table  operators  based  on  the  relational 
algebra.  This  chanter  demonstrates  how  the  data 

manipulation  operations  of  each  selected  application  can  be 
mapped  into  the  conceptual  level  primitives.  Although  not 
the  main  intent  of  this  chapter,  where  appropriate, 
extensions  to  the  typical  operation  are  suggested, 

9.  9ASIC  IASS  PRIMITIVES 

The  six  basic  IASS  primitives  which  can  perform  the 
operations  in  the  functional  Intersection  are  INSERT, 
MODIFY,  OELETE,  PROJECT,  SELECT,  and  UNION.  Each  primitive 
is  set  theoretic  in  that  the  operands  are  tables  and  the 
results  are  tables,  a  table  can  contain  any  number  of  rows. 
A  special  table,  BLANK,  is  defined  to  be  a  row  with  all 
columns  blank  except  for  the  ID,  A  literal  strinq, 
'literal',  can  stand  for  any  character  string  in  which  it  is 
contained.  What  follows  is  a  description  of  the  primitives. 
For  this  discussion  the  following  conventions  will  be  used: 

CD  The  word  table  is  synonymous  with  data  table 

(2)  Whenever  two  tables  are  used  in  an  operation, 
tablel  and  table2,  tablet  will  be  the  current  table. 

(3)  Column  names  will  aopear  In  upper  case,  their  value 
will  be  appear  in  lower  case. 
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1-  HULLS 

Given  tablel,  INSERT  adds  tabie2  at  a  specified 
location.  The  operator  is  denoted: 

IN5ERT(iocation,  tabie2,  table!) 

2.  Modify 

Given  a  table,  MODIFY  chanaes  the  value  of  the 
columns  in  tne  rows  of  the  table.  The  operator  Is  denoted: 

MODIFY ( (COLUMN ,  column,  new  vaiuef,  table) 

where  the  3-tuple  ( column ,  column,  new  value)  describes  the 

change  by  column  name,  present  value,  and  tne  new  value. 

The  +  indicates  that  more  than  one  column  car.  be  modified  bv 

0 

a  single  operation.  If  a  chance  to  a  column  value  is  to  be 
made  Irrespective  of  the  present  value,  e.o.  chanoe  any 
value  in  column  NAME  to  'JONES',  that  desire  can  be 
expressed  by  a  special  character,  or  wild  card,  olaced  in 
the  oresent  value  position  of  the  3-tuple. 

3.  Delete 

Given  a  table,  DELETE  deletes  the  sac  of  rows  from 
the  table  that  satisfy  a  specified  condition  based  on  the 
column  values.  This  operator  is  denoted: 

OELETECcondltlon,  table) 

The  ooerands  of  tne  conditional  statement  are  literal  or 
numeric  constants,  arithmetic  expressions,  or  the  eoiumn 
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values  of  the  table.  The  operators  of  the  conditional 


statement  are  the  arithmetic  comoarison  ooerators  C < ,  >,  a, 
4,  >),  the  logical  operators  ( -»  ,  a  ,  v  ) ,  and  the 

arithmetic  operators  (♦,  - ,  *,  /).  The  delete  operator  also 
creates  a  table  that  contains  the  deleted  rows. 

4.  Project 

Given  a  table,  a  projection  of  the  taole  is  made  by 
removing  some  of  its  columns  and/or  rearranoino  some  of  the 
remaining  columns.  A  projection  of  a  table  is  denoted: 

PROJECTCcolumn  list,  table) 

where  column  list  names  the  desired  columns  from  the  table. 

5.  Select 

Given  a  table,  a  selection  returns  the  set  of  rows 
that  satisfy  a  conditional  statement  based  on  the  column 
values.  A  selection  on  the  table  is  denoted  : 

SELECTCeondltion,  table) 


6,  Union 

Given  two  tables,  tablel  and  table2,  the  union 
creates  a  table  whose  rows  are  in  tablel  or  table2,  or  both. 
The  union  operation  is  denoted: 

UNI0N(teble2,  tablel) 

The  schema  of  the  resultant  table  will  be  the  same  as 
tablel.  The  columns  In  table2  whose  content  is  not  the  same 


as  a  column  in  tablel  will  not  be  In  the  resultant  table. 
There  are  two  differences  between  the  union  and  insert 
operators.  First*  union  appends  table2  to  the  bottom  of 
table  1.  Second*  insert  assumes  that  tables  1  and  2  are  the 
same  type. 

C.  REALIZATION  OF  LOGICAL  OPERATIONS 

This  section  demonstrates  that  tne  data  manipulation 
operations  on  the  logical  file  in  the  functional 
intersection  of  each  application  ean  be  exoressed  m  terms 
of  the  conceptual  level  primitives.  It  will  be  assumed  that 
the  underlying  system  maintains  the  ID  column  as  rows  are 
moved  in  a  table.  Its  resolution,  therefore,  win  not  be 
discussed. 

1 .  Text  Processor/Form  Generator 

The  command  sets  of  several  text  Drocessors  and  the 
form  generator  facility  of  DBASE  II  and  the  ZIP  form 
generator  were  reviewed,  and  it  was  found  that  the  text 
processor  set  contained  the  set  of  form  generator  commands. 
Therefore,  these  apolications  win  be  discussed  together, 
a.  Locate 

Positioning  the  cursor  typically  comprises  a 
laroe  portion  of  the  text  processor  and  form  generator 
operations.  The  cursor  can  be  directed  to  a  line  number, 
relative  distance  from  the  current  line,  or  to  a  substring. 
The  result  of  positioning  the  cursor  can  be  considered  to  be 


37 


a  line  reference,  Locating  a  row  in  the  text  or  form  taxt 
data  tabla  is  dona  by: 


SELECTCeondition ,  table) 

Using  the  primitive/  the  text  or  form  text  data  table  can  be 
browsed  by  contiguous  lines  (e.o  ID  >  XI  A  id  4  X2),  or  by 
line  content  (e.g.  TEXT  or  FORM  LINE  a  'substring'AC ID  <  Id 
♦  10)). 

b.  Insert 

Inserting  a  row  into  a  text  or  form  text  data 
table  at  location  ID  is  done  by: 

INSERT  CIO.  BLANK,  table) 

The  same  primitive  can  be  used  to  insert  an  entire  data 
tabie2  into  the  current  data  tablel  at  location  ID: 

INSERTCID,  table2,  tablel) 

c.  Modify 

Inserting  and  deleting  characters  are 
functionally  egulvalent  in  that  they  are  modifications  to 
the  contents  of  a  file.  Assuming  that  the  desired  row  is 
current,  the  operation  to  modify  the  row  in  a  text  or  form 
text  data  table  is: 

MODIFY ( (TEXT  or  FORM  LINE),  'old',  'new',  table) 

The  find  and  replace  operation  is  an  extension  of  inserting 
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or  deleting  characters,  witn  this  operation,  a  row  does  not 
have  to  be  previously  selected.  Also,  a  single  change  to  a 
set  of  rows  Identified  by  a  conditional  expression  based  on 
their  column  values  can  be  done.  The  find  and  replace 
operation  is  done  bv  the  expression* 

MODIFY ( (TEXT  or  FORM  LINE,  'old',  'new'), 

SELECT (condition,  table)) 

d.  Delete 

Deletlnq  a  row  or  set  of  rows  (blocK),  from  a 
text  or  form  text  data  table  is  done  by: 

h£LETE(condltlon ,  table) 

The  condition  can  oe  any  function  of  the  ID  and/or  TEXT  or 
FORM  line  columns.  This  generalization  enhances  the  typical 
text  processor  or  form  generator  operation  since  rows  can  be 
Identified  by  number  or  content  and  a  bloc*  does  not  have  to 
be  a  contiguous  set  of  rows. 

e.  Copy 

Copying  lines  in  a  text  or  form  text  data  table 
can  be  done  by  the  expression: 

INSERT (ID, SELECT (condition,  table),  table) 

Any  portion  of  a  text  or  form  text  data  tablet  can  be  copied 
to  or  saved  to  another  tabie2  by  the  expressions: 
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UNION (SELECT (condition ,  tablel),  table2) 

or 

UNiON(OELETE(conditlon,  tablel),  table2) 


The  general  nature  of  the  primitives  enhance  the  tyoical 
text  processor  or  form  generator  operation  by  allowing  the 
lines  to  be  Identified  by  content  and  not  requirlno  that  a 
bloc*  be  contiguous,  For  exanole,  the  statement: 

UNION  (SELECT  (TEXT  LINE  s  '4bC'A.(IC  <  10), 
taelel),  tacle2) 

would  cooy  to  taole2,  any  line  in  tablel  with  ID  less  than 
10  and  whose  TEXT  LINE  column  contains  tne  character 
substring  ABC , 

f.  Move 

Movina  rows  or  a  bloc*  in  a  text  or  form  text 
data  table  to  location  10  Is  done  by  tne  excresslon: 

INSERT ( ID ,  DELETE ( cond it Ion ,  taole),  table) 


The  condition  can  be  any  function  of  tne  ID  and/or  text  or 
form  line  columns.  This  Generalization  enhances  the  tvoical 
text  processor  or  form  generator  ooeration  which  reauires 
that  line  numbers  be  Known  and  a  slocx  of  lines  be 
contiguous . 


The  UNIX  mail  utility  is  an  elaborate  system  which 


is  closely  coupled  to  the  operating  system,  viewed  as  a 


database  taole. 


the  complexity  Is  reduced 


A  set  of 


essential  mall  operations  were  deduced  from  the  UNIX  mall 
system. 

a.  Locate 

Displaying  messages  for  reading  or  editing  can 

be  done  by: 


SELECT(condltlon ,  table) 

using  the  orimltlves,  the  message  to  oe  displayed  can  be 
described  by  any  condition  of  the  columns  of  the  mail  data 
table.  This  would  oreclude  the  user  from  having  to  Drowse 
the  mail  data  table  first  to  determine  which  messaqes  miaht 
be  of  interest  and  then  listina  them  oy  number. 

A  summary  of  the  messaoes  can  be  displayed  by 
selecting  a  set  of  messages  which  satisfy  a  condition  and 
then  disolaying  the  desired  columns: 

PROJECT (column  list,  SELECTCconditlon ,  table)) 

By  using  the  primitives,  the  user  is  not  restricted  to  the 
predefined  message  summary, 
b.  Insert 

A  message  can  be  created  by  appending  a  blank 
row  into  the  mall  data  table  and  modifying  its  null 
contents: 

UNION ( BLANK ,  table) 

MODIFY ( (COLUMN,  g,  #new'), 

SELECT (  all  columns  s  0,  table)) 
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Alternately,  a  Message  can  be  created  at  any  location,  ID, 
in  tne  aall  table  by  the  expressions 

INSERT! ID,  BLANK,  table) 

NODirYC (COLUMN,  0,  'new') , 

SELECT (  all  eoluens  *  0,  table)) 

Regardless  of  the  method  used,  the  3-tuple  list  In  the 
modify  ooerator  contains  a  see  of  values  for  each  column  in 
the  mail  table  exceot  the  ID.  The  chance  for  each  column  is 
from  null  to  the  desired  value  suopiied  by  the  user. 

Messages  addressed  to  a  user  can  be  oictced  up 
from  any  mall  data  table2  by  the  expression: 

UNION(DELETECT0  a  'user',  table? ) ,  tablet ) 

Messaaes  can  be  olcKed  up  from  a  mail  data  table?  that 
satisfy  any  specified  condition  bv  the  general  expression: 

UNION! DELETE ( condition ,  tabie2),  tablet) 

Finally,  an  entire  mall  table2  can  be  inserted  into  mall 
tablet  at  location  ID  by: 

INSERTdD,  table2,  tablet) 

c.  Modify 

Assuming  that  a  message  has  been  selected,  any 
field  in  the  message  can  be  edited  by  the  operation: 

**0DIFY( (COLUMN,  column,  new  value),  table) 
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Th«  sane  change  can  be  made  to  several  messages  wnlch 
satisfy  a  specified  condition  by  slightly  modifying  the 
basic  operation: 

MODIFY ((COLUMN,  column,  new  value), 
SELECT(condition,  table)) 

d,  Delete 

Messages  can  be  deleted  from  a  man  data  table 
cased  on  any  column  condition  bv  the  expression: 

DELETE(condition,  table) 

Using  the  primitives,  a  user  is  not  restricted  to  a 
predefined  method  of  deleting  messages.  <*itn  one  operation, 
any  set  of  messages  can  be  identified  and  deleted. 

e.  Copy 

There  may  oe  an  occasion  «nen  a  codv  of  a 
message  in  a  mail  data  table  needs  to  be  made,  Cooyina  a 
message  can  be  done  by: 

UNION (SELECT (condition,  table),  taole) 

Messages  can  be  copied  or  saved  to  another  mail  data  taole2 
by  the  expressions: 

union (SELECT (condition,  tablet),  table2) 

or 

UNION(DELETE(condltion,  table!),  table2) 
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f •  MOVC 


Messages  In  a  nail  data  taele  are  not  ordered. 
They  ean  be  aoved  within  a  mail  data  table  to  location  ID  by 
the  expressloni 

INSERT (ID, DELETECcond ition, table) ,  table) 

3.  Electronic  Spread  Sheet 

As  was  noted  in  charter  2,  the  typical  spread  sheet 
view  is  not  the  spread  sneet  data  table.  However,  data 
manipulation  operations  on  the  view  can  be  translated  into 
the  operations  on  the  spread  sheet  deta  table, 
a.  Locate 

Entry  positions  in  the  spread  sheet  view  are 
referenced  by  x  and  Y  oosition.  As  a  result  of  the  locate 
operation,  the  function  field  is  displayed.  Locatlnq  entry 
oosition  c,  r  in  the  table  is  done  by  the  expression; 

PROJECT (FUNCTION ,  S ELECT(X  *  c  A  Y  s  r,  table)) 

The  expression  suggests  that  an  entry  position  can  be 
located  by  any  other  column  in  the  spread  sheet  date  table 
by  the  expressions 

PROJECT (FUNCTION,  SELECTCeondition,  table)) 

A  problem  with  visiCALC  is  that  a  model  cannot  be  debugged 
very  easily  since  the  only  one  entry  oosition  can  be 
referenced  at  any  time.  The  general  nature  of  the  primitive 
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operators  enhances  the  debugolng  capability  by  allowing  a 
set  of  entry  oosltions  to  be  located  In  the  spread  sheet 
data  table  by  any  condition  of  the  column  values.  For 
example#  all  entry  positions  which  have  a  VALUE  greater  than 
10  can  be  found  by  the  single  operation: 

SEL£CT( VALUE  >  10,  table) 

This  same  action  using  the  VISICALC  command  set  would 
require  the  user  to  locate  the  entry  positions  one-by-one. 
b.  Insert 

One  row  In  the  spread  sheet  view  is  comoosed  of 
C  rows  In  the  spread  sheet  data  table  (C  =  number  of  columns 
in  the  view).  Insertlnq  one  row  in  the  spread  sheet  view  at 
r.  Is  done  by  C  Iterations  of  the  expressions: 

union ( blank ,  table) 

MODIFY  (  (  (  X ,  JB,  X  )  ,  ( Y  ,  0,  r)), 

SELECT  (X  *  f»AY  s  0,  table)) 

In  the  expression,  x  Is  an  element  of  the  column  set  <1..C>. 

One  column  In  the  soread  sheet  view  is  comoosed 
of  R  rows  In  the  spread  sheet  data  table  (R  a  number  of  rows 
In  the  view),  Insertlno  a  column  In  the  soread  sheet  view 
at  d,  is  done  by  R  Iterations  of  the  expressions: 

UNION ( BLANK ,  table) 

MODIFY (C(X,0,d),(Y,0,y)), 

SELECT ( X  a  jBAY  s  t,  table)) 

In  the  expression,  y  Is  an  element  of  the  row  set  <l..R>. 


Two  spread  sheets  can  be  appended  together  to 
form  one  composite  table  by: 

UNiON(table2,  tablet) 

Following  a  row  or  column  Insertion,  further 
processing  has  to  be  done  to  move  the  successor  rows  or 
columns  in  tne  spread  sheet  view.  Moving  rows  or  columns  is 
discussed  in  subsection  f.  After  the  rows  or  columns  are 
moved,  the  entry  positions  that  use  the  value  of  a  moved 
entry  position  as  an  operand  in  the  FUNCTION  column  must  be 
found  and  modified.  This  process  is  described  in  subsection 
c.  Finally,  the  modified  FUNCTIONS  must  oe  evaluated  and 
the  new  entry  position  VALUE  dismayed, 
c.  Modify 

A  value  or  label  entry  operation  in  visicalc  is 
done  to  change  the  value  of  the  FUNCTION  column  of  the 
current  entry  position.  The  expression  is: 

mODIFY((FUNCTION,  function  ,  new  function),  table) 

rfovina  an  entry  position  (X  s  e ,  Y  *  c),  in  the 
spread  sheet  view  by  changing  the  X  or  Y  value  (X  *  c,  Y  * 
r)  may  reauire  a  subsequent  modification  to  the  FUNCTION 
column  of  the  entry  positions  that  use  e,  d  as  an  operand. 
The  primitive  expression  to  find  and  modify  all  of  these 
dependent  entry  positions  is: 
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MODIFY ( (FUNCTION ,  #ep',  'cr'J, 

SELECT (FUNCTION  »  *eP#,  table)) 


The  current  entry  position  can  be  blanked  by  the 


expression: 


MODIFYt (FUNCTION,  function,  6),  table) 

Clearino  all  entry  positions  in  the  spread  sheet  view  can  be 
done  as  a  special  case  of  the  blanking  action  previously 
described.  Instead  of  the  table  being  a  previously 
selected  row,  it  is  in  this  case,  the  entire  table: 

MODIFY ((FUNCTION,  function,  *) ,  table) 

After  modifylna  the  FUNCTION  column  of  an  entry 
position,  the  FUNCTION  must  be  evaluated  and  the  new  entry 
nosition  VALUE  displayed. 

The  visiCALC  format  commands  deal  with  the 
visual  display  of  entry  positions.  Formatting  an  entry 
position  reauires  a  modification  to  the  format  column  in  the 
spread  sheet  data  table.  Changing  the  format  o*  the  current 
entry  position  Is  done  by: 

MODIFY( (FORMAT,  format,  new  format),  table) 

One  format  chanae  can  be  made  to  a  set  of  entry  positions 
which  satisfy  a  specified  condition  by  the  operation: 

MODIFY( (FORMAT,  format,  new  format), 
SELFCTCcondltlon,  table)) 
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d.  Delete 


One  row  from  the  spread  sheet  view  ean  be 
deleted  with  the  VZSZCALC  command  set.  Since  one  row.  r.  In 
the  view  is  composed  of  c  rows  in  the  spread  sheet  data 
table.  (C  *  total  number  of  rows  in  the  view)  that  many  must 
be  deleted  from  the  spread  sheet  data  table.  The  operation 
Is : 


DELETECY  a  r.  table) 

Although  the  VISXCALC  command  set  does  not  allow  multiple 
rows  to  be  deleted,  the  basic  delete  operation  can  be 
modified  to  delete  a  bloc*  C Y 1  through  Y2)  In  the  spread 
sheet  view: 

DELETECY  >  Y1 A  Y  $  Y2,  table) 

Deleting  a  column  is  similar  to  deletlna  a  row. 
Since  a  column,  c.  In  the  spread  sheet  view  is  comoosed  of  R 
rows  (R  a  number  of  rows  In  the  view)  In  the  spread  sheet 
data  table,  that  many  are  deleted  by  the  single  expression: 

DELETE (X  a  e,  table) 

This  operation  ean  be  enhanced  to  allow  the  deletion  of  a 
set  of  columns  (Xl  through  X2)s 


hELETECX  i  X1A  X  ,<  X2,  table) 


Following  a  row  or  column  deletion,  further 
processing  Is  needed  on  the  table,  in  the  view,  a  deletion 
requires  that  all  rows  and  columns  be  moved  to  fill  in  the 
blank.  Moving  rows  and  columns  is  discussed  in  subsection 
f.  After  the  rows  or  columns  are  moved,  all  of  the 
dependent  tuoles  must  be  found  and  their  FUNCTIONS  modified 
to  correspond  to  the  new  positions.  Finally,  the  modified 
FUNCTIONS  must  be  evaluated  and  the  new  entry  position 
VALUES  displayed. 

e.  Copy 

Copying  the  current  entry  position  (X  a  e,  Y  a 
o),  to  any  other  position  (x  a  c,  Y  a  r),  in  the  spread 

sheet  view,  can  be  done  by  the  expression: 

# 

MODIFY  (  (COLUMN  ,  column,  (e,D)  .column)*,  SELECT  cx  8  CA 

Y  3  r,  table)) 

If  the  destination  entry  position  (X  a  c,  Y  a  r)  Is  not 
found,  a  new  tuple  must  be  entered  Into  the  soread  sheet 
table  and  Its  null  contents  modified: 

UNIONCBLANK,  table) 

MODIFY  ( (COLUMN ,  J8,  ( e ,  p ).  column ) ,  SELECTCX  a  flf  A 

Y  a  JB,  table)) 

For  the  entry  position  (X  *  c,  Y  a  r),  the  3-tuele  list 
contains  a  change  for  each  column  except  X  and  Y,  to  the 
value  of  the  same  column  in  entry  position  at  (X  a  e,  Y  *  p). 
Although  order  In  the  spread  sheet  data  table  is 


49 


insignificant,  the  entry  position  can  be  copied  to  a 
specified  location  by  substituting  the  insert  operator  for 
the  union  In  the  previous  expression: 

INSERT ( ID ,  BLANK,  table) 

A  column  of  height  h,  can  be  created  in  the 
view  by  making  h  copies  of  tne  entry  Position  at  x  *  e  Y  s 
p.  In  the  spread  sheet  data  table,  the  operation  can  be 
done  by  selecting  the  rows  witn  a  Y  value  in  the  height 
ranoe  (r  through  s)  of  the  column,  c,  in  the  view,  and 
making  the  same  chanoe  to  the  value,  function,  and  format 
columns.  The  operation  is: 

“ODIFY(  CCOLI'MN,  column,  Ce,p)  .column)4",  SELECT cx  a  CA 

(Y  »  r  a  y  $  s) ,  table) ) 

Copying  a  column  of  height  h,  can  be  done  by 
making  h  calls  to  the  copy  one  entry  position  orocess.  On 
each  call,  the  Y  value  for  both  the  origin  and  target  entry 
position  is  Incremented  by  one. 

Bakina  n  codes  of  one  column  can  be  done  by 
making  n  calls  to  the  copy  one  column  process.  On  each 
call,  the  X  value  Is  chanqed, 

Copyinq  a  row  of  length  1,  can  be  done  by  making 
1  calls  to  the  eooy  one  entry  position  process.  On  each 
call,  the  X  value  for  both  origin  and  target  entry  position 
is  Incremented  by  one. 
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Maklno  m  copies  of  a  row  could  be  done  by  malting 
m  ealls  to  the  copy  one  row  process,  Qn  each  call,  the  Y 
value  would  be  chanced. 

Any  rectangular  portion  of  a  soread  sheet  view 
in  spread  sheet  tablel,  (Y1  through  Y2)  bv  (XI  throuqn  X2), 
can  be  eooied  to  or  saved  to  another  soread  sneet  in  soread 
sheet  taole2.  This  ooeration  is  done  oy  the  exoression: 

UNION  (SELECT  ( ( Y  i  YlAK  s<  Y2)A(X  »  X1A  X  *  X2),  tablel), 
table2) 

or 

UNIONfDELETE((Y  £  Y1 A  Y  «  Y2)A(X  £  X1AX  <  X2),  tablet), 
table2) 

f.  Move 

A  row  move,  from  r  to  s,  in  the  soread  sheet 
view  can  be  done  In  the  table  by  modifying  the  -  Y  value  of 
the  C  rows  in  the  spread  sneet  data  table.  The  exoression 
is: 

MOOIFY((r,  r,  S),  SELECT ( Y  s  r,  table)) 

A  set  of  rows  (r  through  s)  can  be  moved  by  the  same 
exoression  with  a  different  with  a  different  set  of 
parameters : 

MODIFY  ( ( Y ,  y,  y  -  lr  -  si),  SEIECT(Y  >,  rA  J  v<  s,  table)) 

This  exoression  is  for  the  case  where  the  set  of  rows  is 
moved  ud.  To  move  the  set  of  rows  down,  the  new  value  in  the 
3-tuple  would  nave  to  be  modified  to  y  ♦  lr  -si. 


Moving  a  column  In  Che  spread  sheet  view  Is  done 
with  the  same  primitives.  The  process  will  not  be 
reiterated  exeept  to  mention  that  each  occurrence  of  Y  In 
the  original  expressions  would  have  to  be  changed  to  X. 

After  moving  rows  or  columns,  deoendent  entry 
positions  have  to  be  found  and  their  FUNCTION  columns 
modified  to  reflect  the  new  positions.  Finally,  the 
modified  FUNCTIONS  must  be  evaluated  and  the  new  entry 
position  VALUE  displayed  in  the  view. 


IV.  IASS  EXTENSIBILITY 

A.  COMBINING  IASS  TABLES 

From  the  review  of  the  commercial  application  systems, 
it  is  clear  that  the  non-DBMS  applications  selected  for  this 
study  orovide  functions  to  manipulate  data  in  one  looical 
file.  Combining  files,  of  the  same  type,  can  be  done  by 
appending  files  together  or  inserting  one  into  another.  As 
a  result  of  these  file  combinations,  however,  no  new 
relationships  are  developed  nor  can  information  be  deduced 
from  the  action.  Using  the  relational  database  model  as  the 
common  data  model,  there  are  a  set  of  binary  operators  which 
can  be  used  to  combine  tables  to  form  new  relatlonshios  and 
derive  information.  These  operators  Union,  set  difference, 
INTERSECTION ,  JOIN,  and  NATURAL  JOIN  are  defined  in  unman 
CRef.  21.  This  chapter  explores  the  semantics  of  comoining 
the  data  tables  by  these  ooerators.  Speculation  of  this 
nature  can  result  in  numerous  table  combinations  which  could 
ootentiaily  define  a  new  application.  This  review  is  not 
oresumed  to  be  exhaustive,  but  merely  sugoests  the 
meaningfulness  of  and  potential  uses  for  the  IASS  table 
combining  operators. 
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B.  IMTffA  TYPE  COMBINATIONS 


This  section  considers  the  effect  of  combining  data 
tables  of  the  same  type  by  the  operators  SET  DIFFERENCE, 
INTERSECTION,  JOIN,  and  NATURAL  JOIN,  The  union  operator 
will  not  be  discussed  since  each  application  can  use  It  to 
support  an  existing  function. 

1 «  Text/Form 

Due  to  the  similarities  in  the  text  and  form  tables, 
the  semantics  of  the  intra  table  combinations  will  be 
discussed  together. 

a.  Set  Difference 

The  set  difference  operator  would  be  meaningful 
within  the  context  of  text  processing  and  form  aeneratina. 
It  could  be  used  in  applications  which  reouire  a  iioe-by» 
line  comoarlson  between  two  tables.  For  examDie,  it  Is 
often  necessary  to  comoare  two  versions  of  the  same  computer 
proaram  In  the  course  of  orooram  development  or  two  versions 
of  the  same  form  during  design.  By  apolylna  the  set 
difference  ooerator  on  two  tables  R  and  S,  a  listlna  of  all 
the  lines  In  R  that  are  not  duplicated  In  S  would  be 
returned. 

The  set  difference  ooerator  would  also  be  useful 
In  an  application  to  extract  entire  sections  from  a  table. 
Used  In  this  way,  the  ooerator  would  represent  the  inverse 
of  the  union  or  insertion  operators  to  build  a  comoosite 
table.  From  the  comoosite  table  R ,  those  same  sections,  S, 
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could  bo  dlroctly  removed  by  performing  a  sec  difference. 
Similarly.  Che  see  difference  could  also  be  useful  to  remove 
lines  from  a  table.  R «  that  were  contained  In  table.  S. 

b.  Intersection 

The  Intersection  of  two  tables  would  be 
meaningful  within  the  context  of  text  processing  or  form 
generating.  It  could  De  used  In  aooitcatlons  requiring  a 
llne-ty-llne  comoarlson  or  to  match  supstrlna  patterns  of 
two  tables  to  determine  their  similarities.  For  example, 
comparing  versions  of  the  same  table  to  check  their 
consistency  could  be  done  bv  taking  the  Intersection.  This 
operator  also  sugaests  that  two  unrelated  tables  could  be 
compared  to  determine  their  "closeness".  The  resultant 
table  could  oe  used  to  deduce  similarities  between  the  two 
tables  based  on  the  fact  that  they  contained  identical 
lines,  or  used  to  selectively  remove  duolicate  lines  from 
either  table. 

c.  Join 

Joining  two  text  tables  or  form  text  tables 
would  be  meaningful.  It  could  be  used  in  an  application 
which  required  two  tables  to  be  In  context  simultaneously. 
For  example,  tables  eguiloined  on  their  ID  number  would 
produce  a  split-screen  effeet  to  review  and  edit  them 
slde-by-slde.  This  combination  would  be  particularly  useful 
If  the  contents  of  one  table  was  dependent  on  or  related  to 
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the  contents  of  the  other.  The  seme  operetion  would  be  a 


method  to  produce  a  multi-columned  table  from  two  tables. 
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Joining  two  tables  would  also  be  useful  in 
applications  which  required  a  comparison  of  the  lines  of  two 
tables.  Because  the  join  performs  a  cartesian  product  it 
would  be  unlikely  that  lines  could  be  compared  other  than  as 
to  their  eouality.  Since  the  join  uses  a  selection 
operator,  the  join  could  determine  equality  by  matching  a 
line  In  R  as  a  substrino  in  S  or  vice  versa.  An  equijoln  on 
the  contents  in  two  tables  would  produce  a  table  which  would 
list  the  lines  in  R  next  to  the  lines  S  that  were  equal. 
This  could  be  used  to  determine  the  similarity  between  two 
tables  with  finer  resolution  than  that  available  by  taking 
the  intersection. 

d.  Natural  Join 

To  do  a  natural  join  of  text  tables  or  form 
tables  would  be  meaningful.  A  natural  join  between  two 
tables  would  produce  similar  results  as  those  obtained  by 
dolno  an  intersection  or  an  equijoln  on  the  table  contents. 
An  apoileatlon  in  which  the  natural  join  could  be  used  would 
again  be  to  produce  a  table  based  on  the  equality  of  lines 
contained  in  two  separate  tables.  Instead  of  creating  a 
table  whieh  contained  a  line  from  each  taoie  in  one  row,  the 
resultant  table  would  contain  only  lines  from  one.  As  with 
the  equijoln,  the  lines  returned  could  be  a  substrino  mateh. 
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2.  Mall 


a.  Sat  Difference 

The  set  difference  operator  would  be  meaningful 
In  a  mall  utility.  An  apollcation  in  which  the  operation 
would  be  useful  Is  to  eliminate  duplicate  messages  from 
several  mall  tables. 

b.  intersection 

The  intersection  of  two  mail  tables  would  be 
meaningful.  By  doing  an  intersection,  duolicate  messages 
could  be  located  in  several  mall  tables.  This  information 
could  be  used  to  selectively  manage  the  message  tables  and 
control  the  number  of  message  copies  in  the  entire  system, 
e.  Join 

The  join  of  two  mail  tables  would  be  useful  in  a 
mall  utility.  It  could  be  used  in  an  aDOllcatlon  such  as 
automatic  readdressing.  For  examole,  consider  the  set  of 
messages  that  have  the  same  subject,  A  redolent  could  be 
in  mail  table  R  by  virtue  of  the  fact  that  it  has  received 
at  least  one  message  oertaining  to  the  subject.  This  mall 
table  in  effect  would  represent  a  channel  defined  bv  the 
common  subject.  As  messages  are  received  in  the  mall  table 
S.  an  eguijoin  on  the  SUBJECT  column  between  mail  table  R 
and  mall  table  S  followed  by  a  projection  of  R. header  and 
S.Body  would  ereate  a  copy  of  the  new  message  for  each 
recipient  in  mall  table. 
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The  join  of  two  mall  tables  would  also  be 

meaningful  In  an  ad  hoe  aoolleation  to  find  messages  In  two 
mall  tables  whose  fields  have  a  specified  relationship,  For 
example*  a  join  eould  be  done  to  return  ail  of  the  messages 
In  R  and  S  such  that  they  were  from  the  same  addressee  but 
the  messages  In  3  were  dated. after  the  messaoes  In  R. 
d.  Natural  Join 

A  natural  join  on  two  mall  tables  would  be 

meaningful.  Since  the  BODY  column  of  a  message  is  textual* 
two  messaoes  could  be  considered  to  be  equal  if  one  was  a 

substring  match  of  the  other.  A  natural  join  on  two  mall 

tables  R  and  S  would  therefore,  return  all  messages  In  R 
which  had  the  same  header  as  a  message  in  S  and  whose  body 
was  either  duolicated*  a  subset  of*  or  a  suDerset  of  the 
body  of  the  message  In  S. 

3.  Soread  Sheet 

a.  Set  Difference 

The  set  difference  operator  would  be  meaningful 
in  a  spread  sheet  application.  It  could  be  used  to  compare 
two  instances  of  the  same  model.  For  example,  if  snread 
sheet  R  contained  a  model  with  one  set  of  oarameters,  and 
soread  sheet  S  contained  the  same  model  with  a  different  set 
of  parameters*  the  set  difference  would  produce  a  spread 
sheet  view  which  showed  each  entry  oosltion  in  R  that  was 


different  in  s 


o.  Intersection 


An  intersection  of  two  spread  sheet  tables  would 
be  meanlnqful,  It  could  be  used  to  produce  a  spread  sheet 
used  to  compare  different  Instances  of  the  same  model.  The 
resultant  table  in  this  application  would  show  the  entry 
positions  that  remained  constant  alven  a  different  set  of 
parameters. 

e.  Join 

The  join  of  two  spread  sheet  tables  would  be 
meaninqful.  If  the  spread  sheets  were  the  same  model  with 
different  parameters,  an  equijoin  on  the  position  fields 
would  be  a  way  to  produce  a  table  so  that  two  spread  sheets 
could  be  compared  side-by-side.  A  process  could  be 
developed  which  could  be  used  to  toggle  between  the  snread 
sheet  in  view.  In  this  way,  eaeh  spread  sheet  maintains  it 
loqlcai  indeoendence , 

A  Join  between  two  spread  sheet  tables  would  be 
the  only  way  their  contents  could  be  compared  by  column 
relationships.  For  example,  a  Join  could  be  done  to 
directly  determine  the  differences  between  two  instances  of 
tne  same  modal  or  the  same  Instance  of  a  problem  in  two 
different  models.  The  Join  on  F  and  S  such  that  the  X  and  Y 
positions  ware  the  same  but  the  VALUE  in  R  was  in  a 
specified  relationship  to  the  VALUE  In  S  would  return  a 
table  which  contained  the  entry  positions  in  R  and  S  which 
satisfied  the  condition. 
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d.  Natural  Join 

A  natural  join  on  two  spread  sheet  tables  would 
produee  the  same  effect  as  the  Intersection. 

C.  INTER  TYPE  COMBINATIONS 


This  section  considers 

the 

effects 

of  combining 

data 

tables  of 

different  tyoes  by 

the 

operators  UNION 

,  SET 

DIFFERENCE, 

INTERSECTION, 

JOIN, 

and 

NATURAL  JOIN. 

Some 

table  operations  are  not  syntactically  feasible  on  certain 
table  types  and  therefore  are  not  addressed. 

1 .  Text 

a.  union 

The  union  between  a  text  table  and  a  form  table 
would  be  meaningful.  For  example,  the  body  of  a  letter  can 
be  Kent  in  a  text  table.  By  unioning  It  to  a  form  table 
containing  a  letter  head,  a  form  letter  would  be  created. 

The  union  between  a  text  table  and  mall  table 
would  be  meaningful.  An  application  in  which  this  ooeratlon 
would  be  useful  to  create  a  text  table  from  the  bodies  of 
several  messages  In  a  mall  data  table. 

The  union  between  a  text  table  and  a  soread 
sheet  table  would  be  meaningful.  By  anpendlng  a  soread 
sheet  table  onto  a  text  table,  the  FUNCTION  column  data 
could  be  included  in  a  text  table,  possibly  to  be  sent  to  an 
Individual  In  a  letter. 
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The  union  between  a  text  table  and  a  database 

table  would  be  meaningful.  If  a  database  table  contained  a 

textual  column,  for  example  a  literal  description  of  an 
object,  the  data  in  that  column  could  be  included  in  a  text 
table.  Conversely,  a  textual  description  about  an  object 

could  be  kept  in  a  text  table.  By  unioning  the  text  table 

onto  the  database  table,  the  data  for  the  textual  column 
would  be  provided, 

b.  Set  Difference 

The  set  difference  between  a  text  table  and  a 
form  table  would  be  meaningful.  An  application  to  remove 
text  lines  from  a  text  table  which  were  also  In  a  form  could 
use  the  set  difference.  A  set  difference  between  a  text 
table  and  any  of  the  other  table  types  would  not  be 
syntactically  meaningful. 

c.  Intersection 

The  intersection  between  a  text  table  and  a  form 
table  would  be  meaningful  in  an  application  to  determine  the 
text  lines  that  were  common  In  the  tables.  By  this 
operation  it  could  be  determined  If  a  form  letter  contained 
the  a  body  stored  in  the  text  table.  An  intersection 
between  a  text  table  and  any  of  the  other  table  types  would 
not  be  syntactically  meaningful. 

d.  Join 

A  join  between  a  text  table  and  a  form  table 
would  be  meaningful,  A  text  table  can  oe  joined  with  a  form 
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table  on  the  ID  field*  which  could  be  used  to  produce  e  form 
with  a  textual  description.  Either  portion  of  this 
composite  table  could  be  separately  edited.  An  eauljoln  on 
the  lines  of  the  text  and  form  tables  would  return  the  lines 
which  were  common  In  both  tables. 

A  join  between  a  text  table  and  a  mail  table 
would  be  meanlnoful.  If  the  text  table  had  one  subject  on 
each  TEXT  LINE,  by  doing  an  equijoln  on  the  TEXT  LINE  and 
the  message  SUBJECT,  a  text  table  can  oe  created  which 
contains  the  message  bodies  pertaining  to  a  set  of  subjects 
which  are  of  Interest.  This  could  be  a  method  of  collating 
the  messages  from  several  system  users  concerning  a 
particular  subject  Into  a  single  document. 

a  join  between  a  text  table  and  a  database  table 
would  be  meaningful.  For  example.  If  a  database  table 
contained  a  textual  column,  the  column  In  the  database  table 
could  contain  the  ID  of  a  text  line.  An  equijoln  on  the 
database  column  and  text  line  would  supply  the  text  for  the 
database  tuple.  One  text  line  could  be  contained  in  several 
of  the  database  tuples  and  by  maintaining  one  copy  of  the 
textual  contents,  all  tuples  will  be  assured  of  havlno  the 
same  textual  eolumn  value.  If  the  database  table  contained 
a  mailing  list,  a  join  on  the  database  table  and  the  text 
table  would  be  the  procedure  by  which  a  copy  of  the  text 
table  could  be  made  for  each  entry  in  the  list.  Another 
application  In  which  a  join  would  be  meaningful  between  a 
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text  table  and  database  table  Is  where  the  database  contains 
a  set  of  Keywords  or  Key  phrases.  By  doinq  an  equljoln  on 
the  TEXT  LINE  and  the  Keywords  or  Key  phrases,  every  line  in 
the  text  table  containing  the  Keywords  or  Key  phrases  would 
be  returned.  The  same  application  also  suggests  that  the 
combination  could  be  used  in  support  of  a  word  ehecKing 
program.  Separate  dictionaries  can  be  maintained  in  a 
database  table  and  joined  with  a  text  table.  The  resultant 
tables  could  be  used  to  cheeK  spelling  or  to  analyze  a 
particular  style  of  writing. 

A  join  between  a  text  table  and  a  spread  sheet 
table  would  be  meaningful.  A  narrative  description  about 
one  model  could  be  maintained  in  a  text  table.  Since  it  is 
common  to  store  the  same  model  with  different  parameters  in 
several  spread  sheets,  one  text  table  could  be  joined  to  the 
spread  sheets  by  ID  number  to  document  the  model.  This 
would  be  useful  to  the  user  viewing  tne  spread  sheet  table. 
To  contain  this  additional  information  in  the  view,  would 
require  an  application  soecific  process  which  would  disolay 
the  additional  field. 

e.  Natural  Join 

The  natural  join  between  a  text  table  and  form 
text  table  would  be  meanlnqful  since  the  column  names  are 
synonymous.  It  could  be  used  to  determine  the  lines  of  text 
contained  in  both  tables.  The  resultant  table  would  be  the 
same  as  that  returned  by  taKlnq  the  intersection. 


2.  form 


a.  Union 

The  union  between  a  form  text  table  and  a  text 
table  would  be  meaningful.  An  application  In  which  this 
operation  would  be  useful  would  be  to  generate  a  form  letter 
as  was  addressed  In  subsection  1.  The  union  between  a  form 
text  table  and  e  mall  table  would  be  meaningful.  The  body  of 
a  messaqe  could  be  a  FORM  LINE.  By  unioning  the  form  table 
and  the  mall  table,  a  form  sent  llne-by-llne  throuqh  the 
mall  facility*  could  be  regenerated. 

b.  Set  Difference 

The  set  difference  between  a  form  text  table  and 
text  table  would  be  meaningful.  In  a  similar  aoplleatlon  as 
that  discussed  In  subsection  l,  the  operation  could  be 
useful  to  remove  a  set  of  text  lines  from  a  form,  ft  set 
difference  between  a  form  text  table  and  the  other  table 
types  Is  not  syntactically  feasible. 

c.  Intersection 

The  Intersection  between  a  form  text  table  and  a 
text  table  would  be  meaningful  to  determine  the  common  lines 
of  text  between  the  two  tables  as  was  described  in  subeetlon 
1.  An  Intersection  between  a  form  text  table  and  the  other 
table  types  Is  not  syntactically  feasible. 

d.  Join 

A  join  between  a  form  text  table  and  text  table 
would  be  meaningful  in  applications  discussed  in  subseetlon 
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1.  A  join  between  a  form  text  table  and  a  mail  table  would 
be  meaningful.  A  user  can  sequence  a  FOR*  LINES  and  name  the 
form  In  the  SUBJECT  column  and  send  a  form  line-by-line 
through  the  mall  facility.  A  form  text  table  with  one  line 
can  be  created  containing  the  form  name,  By  an  equljoln  on 
the  FORM  LINE  and  SUBJECT  columns,  all  of  the  FORK  LINES 
could  be  collected  from  the  mall  table.  TKe  form  can  be 
reseouenced  by  the  data  in  the  SUBJECT  column  of  each 
messaqe. 

A  join  between  a  form  text  table  and  database 
table  would  be  meaningful,  A  join  on  the  ID  numbers  between 
a  form  text  table  and  an  associated  database  table  would  be 
useful  to  view  the  two  tables  simultaneously.  The  lines  of 
each  table  In  the  joined  table  could  also  be  edited 
Independently  In  this  form, 

A  join  between  a  form  text  table  and  sDread 
sheet  table  would  be  meaningful.  Since  the  FUNCTION  column 
could  contain  a  reference  to  an  entry  In  a  database  table,  a 
form  text  table  and  spread  sheet  table  could  have  a 
relationship  throuqh  a  common  database.  An  equljoln  on  the 
FUNCTION  column  and  FORK  line  would  return  the  list  of  entry 
oositlons  and  form  lines  which  contained  the  same  database 
reference.  In  the  view,  the  spread  sheet  and  the  filled  out 
form  could  be  displayed.  This  would  be  useful  to  show  a 
spread  sheet  model  and  Its  oarameter  set  in  a  form  in  one 
view. 
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e.  Natural  Join 


A  natural  join  between  a  form  text  table  and 
text  table  would  be  meaningful  In  the  same  application 
described  in  subsection  1. 

3.  Nall 

a.  Union 

The  union  between  a  mail  table  and  text  table 
would  be  meanlnaful.  A  message  can  be  created  by  a  union 
between  a  mall  table  and  text  table  that  contained  a  message 
body  on  one  line.  The  message  header  can  then  be  edited  for 
the  message  created.  Similarly,  a  text  table  of  n  lines 
could  be  unioned  onto  a  mail  table  and  sent  to  a  system 
user,  FPQM,  to,  COPY  TO,  and  DATE  columns  of  n  messages 
would  be  the  same.  The  text  table  name  and  ID  can  be  placed 
in  the  SUBJECT  column  to  direct  the  recipient  in  the 
reconstruction  of  the  text  table. 

The  union  between  the  mall  table  and  a  database 
table  containing  a  textual  column  Is  meaningful.  The  union 
would  be  useful  to  suodIy  a  message  body  from  the  textual 
column.  The  header  of  the  message  could  then  be  edited. 
This  would  be  a  method  to  send  data  in  a  local  database  to 
any  other  user  in  the  system.  Another  application  for  a 
union  between  a  database  end  mall  table  would  be  to  generate 
a  set  of  message  headers  in  a  database  table.  These  headers 
could  be  unioned  onto  a  mail  table  and  then  the  BODY  columns 
provided. 
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b.  Join 

A  join  between  a  mall  table  and  the  form  text 
table  and  text  table  is  meaningful.  For  example,  this 
operation  can  be  used  to  send  a  text  table  or  form  text 
table  to  a  system  user  through  the  mall  facility.  A  set  of 
message  headers  addressed  to  the  same  recipient  contalnlna 
an  ID  in  the  BOOY  column,  could  be  oreoared  In  the  mall 
table.  By  doing  an  eouijoin  on  the  messaqe  BODY  and  the 
text  or  form  text  ID  columns,  and  removing  the  extraneous 
columns,  a  message  containing  each  line  of  the  form  text  or 
text  table  can  be  created. 

A  join  between  a  mail  table  and  a  database  table 
would  be  meaningful.  For  example,  a  message  could  be 
addressed  to  a  group  of  individuals  recognized  by  a  single 
name.  A  database  table  could  contain  the  mapolng  from  that 
single  name  to  the  individual  names.  An  equljoin  between  the 
TO  column  of  the  message  and  the  column  containing  the 
aogreoate  name  in  the  database  would  produce  a  table  which 
contains  a  copy  of  the  original  message  for  each  individual 
included  in  the  group.  This  operation  could  also  be  used  to 
generate  a  message,  Havinq  prepared  the  body  of  a  message 
and  using  a  standard  subject  line,  a  database  table 
containing  a  set  of  headers  including  the  subject,  could  be 
eouijoined  with  a  mail  table  on  the  SUBJECT  columns  to 
produce  the  entire  message.  This  message  generation  method 
is  particularly  useful  in  a  situation  where  the  standard 
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headers  are  always  being  revised.  It  is  also  useful  when  one 
message  needs  to  be  sent  to  several  different  headers  or 
several  messages  of  the  same  subject  need  to  be  sent  to  the 
same  header. 

Finally,  a  message  can  be  created  by  joining  a 
database  table  containing  a  set  of  message  headers  and  a 
text  table  containing  a  message  body  on  each  line.  By 

eoullolnlng  the  two  tables  on  the  ID  column,  one  heading 
would  be  joined  to  one  body,  A  join  on  any  other  column  in 
the  header,  and  the  TEXT  LINE  would  join  every  header  with 
every  body. 

c.  Natural  Join 

The  natural  join  between  a  mail  table  and 

database  table  would  be  meantnaful.  An  apolicatlon  In  which 
a  natural  join  would  be  useful  would  be  to  supoort  routine 
of  incoming  messages.  For  example,  it  is  often  necessary  to 
route  messages  to  Individuals  based  on  the  messaoe  subject. 
If  a  database  were  maintained  which  had  fields  for  the 
subject  and  name  of  a  person,  the  mall  table  could  be 
naturally  joined  to  this  list.  The  result  of  the  action 

would  be  a  table  which  contained  a  copy  of  the  message  for 

each  person. 

4*  amid 

a.  Union 

The  union  between  a  spread  sheet  table  and  a 
database  table  would  be  meaningful.  This  operation  could  be 
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useful  In  a  situation  where  a  spread  sheet  must  contain 
standard  entries.  For  example,  a  database  table  could  be 
maintained  with  a  subset  of  the  spread  sheet  table  columns 
(e.o.  X,  Y ,  and  FUNCTION).  This  database  eould  be  unioned 
onto  a  spread  sheet  table  to  boiler  Plate  the  spread  sheet 
view, 

b.  Join 

the  loin  between  a  spread  sheet  table  and 
database  table  would  be  meaninaful.  For  example,  a  database 
table  could  eontaln  a  set  of  values  which  are  of  special 
significance.  a  conditional  join  based  on  these  values  and 
the  VALUE  column  In  the  spread  sheet  table  would  return  all 

9 

of  the  entry  positions  which  satisfied  the  condition. 
Another  application  in  which  this  combination  would  be 
meaninaful  would  be  to  store  standard  entry  position 
definitions  in  a  database  table.  An  equi^oin  on  the 
position  columns  would  holler  Plate  the  spread  sheet. 
Finally,  an  application  in  which  this  combination  would  be 
meanlnqful  is  to  store  a  set  of  parameters  for  a  spread 
sheet  table  in  a  database  eontalnlnq  columns  for  X,  Y,  and  a 
vector  containing  the  parameter  set,  3y  doing  an  equijoin 
on  the  X  and  Y  columns,  and  removing  all  of  the  columns 
except  the  X,  Y,  fornat,  value,  and  desired  parameter 
column,  the  parameter  set  is  supplied  to  the  model. 
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c.  Natural  Join 


Tha  natural  Join  between  the  spread  sheet  table 
and  a  database  table  would  be  meaningful.  A  database  table 
could  contain  documentation  with  respect  to  each  entry 
position  In  the  spread  sheet  table.  By  doing  a  natural  join 
on  the  X  Y  columns,  a  spread  sheet  table  could  be  documented 
tuple  by  tuple.  This  would  especially  be  useful  If  there 
were  Instances  of  the  same  model  In  separate  soread  sheet 
tables.  For  this  aoplication,  the  line  documentation  would 
only  have  to  maintained  m  one  database  table. 

a  spread  sheet  can.  be  created  from  two  database 
tables.  Database  tablet  could  contain  the  X,  Y,  and  format 
columns  representing  a  oartieular  soread  sheet  format. 
Database  table2  could  contain  the  X',  Y,  value,  and  FUNCTION 
columns  reoreser.tlna  a  standard  model.  By  a  natural  join  of 
the  two  tables,  a  spread  sheet  containing  a  standard  model 
in  a  selected  format  would  be  produced. 


V.  CONCLUSION 


A.  FINDINGS 

Based  on  this  study,  It  can  be  concluded  that  the 
relational  database  model  can  conceptually  supoort  the  data 
representation  and  manipulation  requirements  of  the  selected 
IASS  abdications.  At  the  conceptual  level  each  loalcal 


file  can  be 

represented  as  a 

table 

and  the 

common 

data 

manipulation 

functions  of 

each 

application  In 

Its 

traditional 

form  can  be  expressed  in 

terms  of 

basic 

IASS 

primitives.  In  the  IASS,  higher  level  aoolicatlon  specific 
functions  can  be  defined  in  terms  of  the  lower  level 
primitives.  For  example,  the  COPY,  move,  and  find  and 
REPLACE  functions  can  be  expressed  in  terms  of  the  primitive 
pairs,  INSERT/SELECT ,  INSERT/DELETE,  and  MODIFY/SELECT 
respectively.  In  addition  to  the  intersection  of  commands 
and  functions  that  exists  between  the  IASS  applications 
there  exists  an  Intersection  of  commands  and  functions 
between  subsets  of  the  applications.  For  example, 
formattinq  commands  are  applicable  if  a  user  Is  edition  a 
text  file,  form,  or  message  body.  Also,  aaoregate 
arithmetic  functions  are  common  to  database  and  spread  sheet 
applications.  These  intersections  further  reduce  the  set  of 
application  specific  commands  and  functions  a  user  must 
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The  IASS  also  contains  a  sat  of  four  combining 
operators.  Whan  used  to  combine  tables  of  the  same  type, 
these  operators  can  be  used  to  deduee  information  about  data 
contained  in  two  tables,  and  to  create  new  tables  from 
existing  tables.  Zn  this  way.  the  IASS  enhances  the  basle 
capabilities  of  each  of  the  non-DBMS  aoollcations. 

9v  mapoina  the  looieal  file  into  one  conceotual  data 
object,  data  independence  is  achieved.  Therefore,  the  full 
use  of  the  specifically  designed  data  tables  can  be  realized 
by  removing  their  semantic  identity.  A  data  table  can  be 
used  by  a  logically  different  application  or  it  can  be 
combined  with  a  different  table  type  into  a  table  which 
defines  a  new  relationship.  This  new  table  can  be  created 
for  an  ad  hoc  application  or  for  an  application  added  to  the 
I*SS.  The  ability  to  combine  data  tables  lmoarts  to  the 
IASS,  capabilities  which  are  not  available  from  the  set  of 
disjoint  applications. 

B.  FOLLOW-ON  RESEARCH 

The  first  taste  is  to  re-evaluate  the  logical  data  bases 
designed  tor  the  IASS.  The  present  organization  implies 
that  each  application  is  a  disjoint  database.  This 
perspective  was  useful  for  this  study,  but  it  is  clear  that 
they  must  not  be  disjoint  if  it  implies  that  different  table 


types 

cannot 

be 

combined. 

Another  iteration 

on  the  IASS 

tables 

needs 

to 

be  done 

to  combine  the 

application 
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directories  end  data  table  schemas  Into  tables  in  a 
centrally  maintained  data  dlctlonary/dlreetory. 

After  the  conceptual  level  is  re-evaluated,  the  next 
step  In  the  project  should  be  to  design  the  physical  level 
of  the  IASS  and  design  the  software  to  Implement  the  system. 
It  is  recommended  that  the  first  iteration  of  the 
implementation  be  a  prototype  consisting  of  the  table  data 
object  and  the  ten  IASS  primitives,  to  evaluate  the  utility 
of  the  IASS  to  support  the  needs  of  a  user  in  an  actual 
operating  environment.  Subsequent  iterations  can  Include 
the  DBMS  functions  such  as  data  integrity,  security,  and 
crash  recovery. 

Concurrent  with  the  physical  level  and  software  design, 
the  apoilcatlon  specific  command  languages  and  orotesslng 
proarams  can  be  designed,  th#  text  formatter,  form  ortnter, 
and  spread  sheet  view  generator  can  all  be  designed  based  on 
the  data  table  definitions  and  the  abstract  interfaces  of 
the  primitives. 

Finally,  it  is  recommended  that  the  IASS  be  emulated  on 
an  existing  relational  DBMS  (e.g.  DBASE  II),  The  reason  for 
this  is  two-fold.  First  It  would  provide  an  available  test 
bed  which  can  be  used  to  test  concepts  which  need  to  be 
resolved  before  the  prototype  system  is  delivered.  second, 
it  could  be  used  to  determine  the  manner  in  which  the  IASS 
will  handle  the  fundamental  needs  of  the  user  before  the 


first  prototype  Is  finished,  Zt  would  therefore,  be  a  way  to 
Involve  the  user  In  the  early  deslon  staqes  of  the  IASS. 
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APPENDIX  A:  WORD  STAR 


WORD  STAR  is  a  word  processing  program  developed  by 
Micro-Pro  to  combine  tne  capabilities  of  a  screen  editor  and 
an  on-screen  text  formatter.  The  resuic  is  a  very  powerful 
text  editor  which  displays  the  referenced  file  as  it  will 
appear  on  the  printed  oage. 

word  STAR  is  primarily  menu-driven.  The  commands  which 
are  presently  valid  are  displayed  in  a  menu,  and  are 
executed  by  Keystroke  combinations.  On-line  information  is 
available  to  the  user  concerning  many  other  aspects  of  word 
STAR.  The  menu  driven  feature  eases  user  initiation  to  word 
STAR  and  is  part  of  the  rtelo  facility.  The  level  of  help  is 
selectable  to  match  the  users  level  of  experience,  and 
determines  the  extent  to  which  the  menus  are  displayed  on 
the  CRT. 

'  word  STAR  is  composed  of  a  set  of  seven  hierarchically 
organized  menus  or  environments,  as  shown  in  Table  A.l.  The 
user  enters  word  STAR  in  tne  No-File  environment.  At  this 
point  there  is  no  file  in  reference,  the  ooject  granularity 
is  the  file,  and  the  menu  options  Include  commands  to: 
change  the  logged  disk  drive,  set  the  automatic  directory 
display  feature  (on/off),  set  the  help  level,  orint  a  file, 
rename  a  file,  copy  a  file,  delete  a  file,  run  a  program, 
open  a  document  file,  and  open  a  non-document  file. 


Table  A* 1  -  word  STAR  Menu  Hierarchy 


LEVEL 

MENU 

I 

No 

rile 

2 

Main  Menu 

3 

a. 

Help 

b. 

On-Screen  Format 

e. 

Print  Control 

d. 

Quick  Edit 

e. 

File/BiocK 

word  STAR  recognizes  two  types  of  files,  "document"  and 
"non-document".  A  document  file  can  either  be  a  text  file 
processed  by  a  word  processor  or  a  program  run  oy  a 
computer,  A  non-document  file  is  a  special  ourDose  file 
whicn  is  used  oy  another  software  product,  and  will  not  be 
discussed  further. 

The  on-screen  editor  and  formatter  are  invoked  by 
selecting  tne  menu  option  to  open  a  document  file.  This 
causes  word  STAR  to  enter  the  Main  Menu  environment  with  a 
specific  file  in  reference.  Zf  tne  file  previously  existed 
it  is  made  current,  otherwise  a  new  file  is  created  and  made 
current.  On  entering  the  Main  Menu  environment,  a  status 
line  and  a  rule  are  Initialized.  The  status  line  contains 
information  about  the  system  -  the  name  of  tne  file,  tne 
page  within  tne  file,  the  column  and  row  numoer  tne  cursor 
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is  at,  and  tha  insertion  mode  (on/off).  The  rule  Indicates 
the  right  and  left  margin  position  as  well  as  the  tab 
positions.  The  Main  Menu  represents  the  basic  file  editing 
environment  where  the  user  win  remain  until  it  is  decided 
to  quit  the  current  file  and  return  to  the  No  File  Menu  or 
the  operating  system.  In  any  case,  WORD  star  does  not 
permit  lateral  movement  between  the  sub-menus  of  the  Main 
Menu. 

A  useful  feature  WORD  STAR  employs  is  "word  wrap",  with 
word  wrap,  the  user  does  not  have  to  insert  carriage  returns 
at  the  end  of  each  line.  As  the  text  overruns  the  end  of 
the  line,  word  STAR  automatically  starts  the  next  line.  In 
this  way,  the  user  merely  inputs  an  entire  bloc*  of  text  as 
a  continuous  ASCII  character  string,  and  leaves  the 
formattina  to  the  system.  In  the  Main  Menu,  the  user  can 
edit  tne  tile  in  granularities  of  character,  word,  and  line. 
Insertion  is  a  "toggled"  operation  (on/off),  where  the  user 
is  either  in  insert  mode  or  overwrite  mode.  Any  Keystroke 
entered  is  either  inserted  in  tne  text  at  the  cursor 
position,  shifting  characters  to  the  right  to  accommodate 
it,  or  overwrites  the  character  at  the  cursor  position.  To 
facilitate  on-screen  editing,  the  Main  Menu  contains 
commands  to  control  cursor  movement  and  to  scroll  the 
screen.  It  is  posslole  to  Insert  tabs  or  end-o£-paragrapn 
markers.  There  is  a  "Find  and  Replace"  command  which  can  oe 
repeated  any  numeer  of  times.  Deletions  can  be  done  on  a 
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single  character,  a  word,  or  an  entire  line.  The  Main  Menu 
alto  contains  options  to  select  one  of  the  five  submenus. 

The  Quick  Editing  environment  supports  editing  on  higher 
levels  of  abstraction  of  text  objects  than  the  Main  Menu. 
There  are  additional  cursor  movement  commands  to  give  a 
wider  range  of  control  and  granularity.  As  in  the  Main  Menu 
environment,  the  user  can  scroll  the  display,  but  now  it  is 
continuous  at  nine  user  selectable  rates  until  stopped  oy 
command.  Insertions  are  accomplished  in  tne  same  way  as  in 
the  Main  Menu  environment,  but  deletions  are  possible  on  a 
wider  range  of  objects.  There  is  a  feature  to  allow  a 
command  to  be  repeated  at  one  of  nine  user  selectable  rates, 
until  stopped  by  command. 

The  Block  environment  provides  the  user  a  set  of 
operations  on  a  block  of  text.  word  star  considers  an 
entire  file  to  be  a  special  case  of  a  block  of  text.  Piles 
can  be  saved  by  several  menu  options:  save  and  resume  the 
referenced  file,  save  and  quit  to  the  operating  system,  save 
and  exit  the  referenced  file,  and  copy  to  another  file. 
Files  may  also  be  renamed,  deleted,  printed,  or  quit  without 
saving  changes.  To  support  these  file  operations,  the  Block 
Menu  contains  options  to  chanqe  the  logged  disk,  and  to  turn 
the  automatic  directory  listing  on  or  off.  In  this 
capacity,  the  Block  environment  is  used  as  a  successor  to 
the  Main  or  Quick  Editing  environments  after  the  cursor  is 
positioned.  Blocks  In  a  file  must  be  marked  by  tne  user. 
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As  a  delimited  aggregation  of  text,  a  block  can  be  moved 
within  the  same  file.  Copying  blocks  of  text  can  either  oe 
within  the  referenced  file  or  between  the  referenced  file 
and  an  external  file.  Block  copying  between  files  are  bi¬ 
directional.  Copying  a  block  to  an  external  file  entails 
overwriting  an  existing  file  or  creating  a  new  file. 
Copying  a  block  from  an  external  file  entails  moving  the 
entire  external  file  to  the  point  in  the  text  Indicated  by 
the  cursor.  Any  marked  block  can  also  be  deleted.  As  a 
precautionary  measure,  word  STAR  allows  the  user  to  hide 
block  markers,  and  only  blocks  which  are  vlsloly  marked  can 
be  deleted.  In  addition  to  a  text  block  beinq  organized 
Into  a  continuous,  unstructured  strinq  of  text,  word  STAR 
supports  a  columnar  organization. 

The  previously  described  menus  contain  operations  to 
create,  edit,  position  the  cursor,  or  output  a  text  file. 
The  format  of  the  file,  either  as  it  is  visually  displayed 
or  printed  out,  is  defined  by  a  set  of  formatting  parameters 
associated  with  the  file  or  by  commands  embedded  in  the 
file.  The  formatting  parameters  associated  witn  a  file  are 
initially  set  to  default  values  and  the  set  of  embedded 
commands  Is  initially  empty. 

Formatting  in  word  STAR  is  primarily  done  on-screen  with 
the  options  contained  in  the  On-Screen  Menu.  The  on-screen 
formatting  commands  are  those  whose  effects  can  oe  visually 
displayed,  and  they  are  listed  in  Table  A. 2. 


90 


Table  A. 2  -  WORD  STAR  On-Screen  Formatting  Commands 


1.  Set  left  maroin 
2*  Set  right  margin 

3.  Release  margins 

4,  Set  and  clear  tabs 

5.  indent  a  paragraph 

6.  Create  a  special  rule 

7,  Center  text 

8,  Set  line  spacing 


The  On-Screen  Menu  also  contains  options  in  the  form  of 
(On/Off)  toggles  to  control:  word  wrap,  rule  display, 
variable  tabbina,  hyphenation  help,  riant  margin 
Justification,  soft  hyphen,  print  embedded  control 
characters,  and  page  breatc  display.  if  an  on-screen 
formatting  operation  needs  to  be  applied  to  tne  previous 
contents  of  the  file,  the  applicable  portion  of  the  file 
must  be  reformatted.  Furthermore,  these  formatting 
parameters  are  only  temporarily  applied  when  the  file  is 
referenced.  Any  subseauent  reference  to  a  file  reauires 
that  the  on-screen  formatting  parameters  be  reset. 

WORO  STAR  combines  into  one  menu,  the  Print  Menu,  all 
options  which  create  special  printing  effects  not  normally 
dlsplayable  on  a  video  screen.  There  are  options  to:  bold 
face,  double  stride,  underline,  stride  out,  subscript,  and 
superscript.  Since  the  effects  of  these  options  cannot  be 
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displayed  on  the  video  screen,  a  special  character  is  used 
to  mark  the  affected  area.  Additional  special  printing 
effects  are  selectable  through  this  menu  on  a  one  time 
basis:  overprint  a  character.  Indicate  a  non-break  space, 
and  overprint  a  line.  The  Print  Menu  also  contains  options 
which  control  the  printer  durino  output.  The  user  may  embed 
commands  in  the  text  file  to  cause  the  printer  to  ehanoe 
pitch,  or  cause  a  pause  to  allow  tne  user  to  cnanae  the 
print  element  or  ribbon. 

printing  can  also  be  directed  through  the  use  of 
embedded  dot  commands.  These  commands  are  placed  m  the 
text  file  and  appear  as  regular  text  on  the  display,  but  are 
not  output  to  a  printer  and  force  wgrd  star  to  chanqe  a 
prlntlno  parameter  at  print  time.  Dot  commands  alter  the 
default  parameters  word  STAR  uses  to  format  the  printed 
page.  Table  A. 3  provides  a  listing  of  these  commands. 

Oot-commands  may  be  placed  anywhere  in  the  text,  but 
since  they  are  static  and  tend  to  destroy  the  relationship 
between  what  Is  displayed  and  what  is  printed,  they  are 
usually  placed  at  the  beginning  of  the  text  file.  As  with 
the  options  of  the  Print  Menu,  dot-command  actions  must  be 
supported  by  tne  specific  printer  in  use. 

The  last  menu  to  be  described  Is  the  Help  Menu.  Help  is 
"on-line"  In  that  It  can  be  Invoked  at  any  time  throuoh  the 
Main  Menu,  and  Is  "dynamic"  In  that  the  level  of  help  can  be 
adjusted.  The  level  will  determine  now  much  information  Is 
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displayed  when  an  option  is  selected.  The  Kelp  Menu  options 
display  information  on*  paragraph  reforming,  flags  in  the 
right-hend  margin,  dot  and  print  commands,  status  line, 
ruler  line,  how  to  set  margins  end  tabs,  and  how  to  move 
blocks  of  text. 


Table  A. 3  -  WORD  STAR  Dot  Commands. 


1. 

Set  line  height 

2. 

Set  page  length 

3. 

set  top  margin 

4. 

Set  bottom  margin 

5. 

Generate  headers 

6. 

Generate  footers 

7. 

Set  footer  margin 

9. 

Reset  page  number 

9. 

Offset  page  from  left  side  of 

printer 

to. 

Position  page  number 

11. 

Set  cnaracter  width 

12. 

Force  a  page  break 

13, 

Prevent  a  cage  break 

*  i 

! 

j 

wCRD  STAR  Is  an  excellent  and  very  DODular  word 
processlna  program.  The  screen-oriented  and  on-line 
formatting  features  are  different  from  other  systems  In  that 
they  are  extremely  easy  to  use.  Once  experience  is  gained 
with  wqro  STAR  It  is  difficult  to  use  llne-orlented  editors 
or  off-line  formatting  systems.  The  on-line  help  facility 
makes  WORD  STAR  easy  to  learn  and  user  friendly.  One  aspect 
of  word  STAR  that  could  be  considered  a  disadvantage  is  the 
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larae  command  set.  However*  belno  menu-driven*  the  commands 
not  normally  used  do  not  have  to  be  memorized  since  they  are 
always  listed  In  the  menu. 


APPENDIX  Bi  VI 


"Vi"  is  a  text  editor  used  by  the  UNIX  operating  system 
and  was  created  by  the  University  of  California  at  Berkeley, 
and  Bell  Laboratories. 

VI  (visual)  Is  a  display  oriented  interactive  text 
editor  with  a  command  vocabulary  size  of  aoout  ninety  one. 
The  user  sees  the  CftT  screen  as  a  window  Into  the  text  file 
and  all  editing  operations  are  Immediately  visible.  Line 
numbers  are  not  displayed  and  have  no  real  use  in  vi, 
although  It  Is  posslole  to  find  out  the  number  for  a  line. 
For  the  satce  of  protection  tne  user  does  not  actually  edit 
the  file#  out  a  copy  of  It,  At  the  comdetlon  of  a  session 
the  user  win  indicate  whether  to  Keep  tne  edited  copy  or 
the  original. 

There  are  forty  seven  movement  commands  for  control  of 
the  cursor,  whicn  Is  the  editor's  point  of  reference,  and 
the  screen  display.  Scope  of  movement  is  possible  over 
file,  screen,  paragraph,  section,  sentence,  line,  word,  and 
character  sized  units.  Up  to  twenty  six  locations  in  tne 
file  can  be  marked  for  later  return,  or  specific  locations 
found  that  match  a  desired  character  string.  Table  B.i 
lists  the  cursor  movement  commands  available  in  the  vi 
system.  Note  that  there  Is  duplication,  in  that  more  than 
one  command  does  the  same  thing. 
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Table  B • 1  •  VI  Cursor  Movement  Commands 


1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 

9. 

10. 
11. 
12. 

13. 

14. 

15. 

16. 

17. 

18. 

19. 

20. 
21. 
22. 

23. 

24. 

25. 

26. 

27, 

28. 

29. 

30. 

31. 

32. 

33. 

34. 

35. 

36. 

37. 

38. 

39. 

40. 


Backward  window 
Forward  window 
Seroll  down  * 

Scroll  up  * 

Backspace  one  character  * 

Backspace  a  single  character 
Backup  a  word 

Backup  a  word  during  insert 
Backup  to  beginning  of  werd 
Retreat  to  previous  line  * 

Retreat  to  beginning  of  sentence 

Retreat  to  beginning  of  previous  paragraph 

Retreat  to  previous  section  boundary 

Linefeed  advance  to  next  line 

Advance  to  first  non-white  space  on  next  line 

Advance  to  next  line,  first  white  soace 

Advance  to  next  line,  same  column  * 

Advance  to  next  character  * 

Advance  to  beginning  of  word 
Advance  to  end  of  next  word 
Advance  to  section  boundary 
Advance  to  the  next  typed  character 
Advance  to  beginning  of  next  paragraph 
Move  to  previous  line  * 

Move  to  end  of  current  line  * 

Move  to  balancing  parenthesis  or  orace 
Moves  cursor  to  last  line  on  screen  * 

Moves  cursor  to  middle  of  screen  * 

Move  forward  to  beginning  of  word 

Move  forward  to  end  of  word 

Move  to  first  non-white  space  on  current  line 

Move  to  line  number  t  * 

Search  for  word  * 

Search  forward  for  string  ** 
search  backward  for  string  * 

Searcn  for  next  match  ** 

Repeat  last  single  character  search 
Find  a  single  character,  backwards  * 

Find  a  single  character,  forward  * 

Reverse  direction  of  previous  find 


* 
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Table  B , 1  -  (Cont.) 


41.  Find  first  instance  of  next  character 

42.  Repeat  the  last  search  command  * 

43.  Homes  the  cursor 

44.  Mar*  the  present  position  of  the  cursor  * 

45.  Return  to  marked  position  * 

46.  Redraw  the  screen 

47.  Returns  to  orevious  context 


The  operations  of  insertion#  modification  and  deletion 
are  supported  by  thirty  commands  that  permit  the  user  a 
varied  level  of  object  control.  Items  that  are  Inserted, 
modified  or  deleted  are  Immediately  updated  on  the  screen  to 
give  the  user  a  current  view  of  the  file  status.  The  user 
also  has  the  ability  to  undo  the  previous  command  if  its 
effects  were  undesired.  Most  insertion  and  modification 
commands  are  structured  so  that  they  continue  to  operate 
until  the  user  Issues  a  command  to  terminate  tnem.  Normally 
during  Insertion  the  user  has  control  of  format  in  tnat  new 
lines  are  started  by  entering  a  carriage  return.  However 
there  is  an  option  that  will  let  VI  determine  when  to  start 
a  new  line,  based  on  line  length,  and  let  the  user  just 
enter  text  as  a  continuous  stream.  Table  B.2  lists  the 
thirty  edit  commands. 

In  order  to  use  VI  the  user  issues  the  command  "vi" 
followed  by  the  name  of  the  file  to  be  edited,  if  this  is  a 
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new  file,  then  the  name  will  not  be  found  In  the  directory 
and  VI  will  create  an  empty  file.  After  entry,  the  user  will 
issue  cursor  motion  commands  to  maneuver  through  the  file, 
and  issue  edit  commands  to  change  the  contents  of  the  file. 
There  are  no  other  modes  or  displays  available  in  VI. 


Table  B.2  -  VI  Edit  Command  Summary 


1.  Insert  a  number  of  spaces 

2.  Insert  nonprintable  characters 

3.  Insert  "shif twidth"  blanic  spaces 

4.  Insert  at  the  beginning  of  line 

5.  Insert  at  end  of  line 

6.  Insert  before  the  cursor  ** 

7.  Insert  after  the  cursor  ** 

8.  Insert  new  line  below  current  line 
4,  Insert  new  line  above  current  line 

10,  Insert  text  below  current  line  ** 

11,  Insert  text  aoove  current  line  ** 

12,  Delete  last  cnaracter 

13,  Delete  rest  of  the  text  on  current  line  * 

14,  Delete  character  before  cursor 

15,  Delete  the  following  object 

16,  Delete  single  character  under  cursor  *» 

17,  Repeat  last  command  ** 

18,  Join  together  lines  * 

19,  Replace  single  character  under  cursor 

20,  Replace  characters  at  cursor  ** 

21,  Change  the  entire  line 

22,  Change  single  character 

23,  Change  the  following  object 

24,  Cnange  rest  of  the  text  on  current  line 

25,  Undo  last  change  to  current  buffer  ** 

26,  Restore  current  line  to  previous  condition 

27,  Yanlc  following  object  into  buffer  * 

28,  Yarn?  a  copy  of  current  line  into  buffer 

29,  Repeat  last  text  insertion 

30,  Named  buffer  specification  follows  * 


In  addition  to  the  two  command  categories  already  given 
there  are  additional  commands  of  a  miscellaneous  nature. 
Table  8,3  lists  these  additional  commands. 


Table  B.3  -  Miscellaneous  VI  Commands. 


1.  Print  file  status  message 

2.  Clear  and  redraw  the  screen 

3.  Redraw  the  current  "logical"  screen 

4.  Suspend  or  restart  output 

5.  Cancel  partially  formed  command 

6.  Return  to  position  in  last  edited  file 

7.  Reformat  lines  in  buffer 

8.  Indicate  file  and  option  manipulation 

9.  Quit  VI,  enter  line-oriented  editor 


Some  very  basic  formating  commands  for  line  lenqth  and 
indenting  are  directly  available.  A  macro  creation 
capability  is  present  to  allow  tne  user  to  create 
abbreviations  for  command  strings.  Table  B.4  lists  tnese 
formatting  commands.  VI  makes  no  claim  to  supporting  a 
formatting  package,  since  the  file  will  be  output  in  the 
same  format  the  user  entered  it.  For  special  formatted 
output  a  VI  generated  file  must  be  processed  by  an  off-line 
word  processor,  like  "nrqff  -me"  descrioed  in  Appendix  CD). 

VI  provides  a  nigh  degree  of  support  to  the  user  for 
restructuring  a  file,  or  files.  There  are  nine  buffers 
available  for  storing  deleted  text,  and  twenty  six  buffers 
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to  us*  as  temporary  holding  spaces  while  reordering  and 
editing*  The  text  can  be  taken  from  other  files  and/or 
buffers*  for  use  in  the  file  currently  being  edited.  If 
needed,  previously  deleted  text  from  the  current  file  can  be 
recovered,  and  also  other  files* 

Table  B.4  -  VI  Formatting  Commands. 

1*  Reformatting  command 

2.  Shift  lines  left  one  "snif twldth" 

3*  Reindent  lines 

4.  Shift  lines  right  one  "sniftwidth" 

5.  Prints  current  file  contents 


"VI"  is  a  good  screen  oriented  editor  and  has  a  wide 
range  of  capabilities,  however  it  has  some  drawbacks. 

(1}  It  has  a  poorly  designed  user  interface  since  the 
command  vocabulary  is  very  large  and  tne  individual  command 
strings  are  difficult  to  remember.  There  does  not  seem  to 
have  been  much  thought  given  to  the  design  of  the  command 
vocabulary. 

(2)  It  takes  a  fairly  long  time  to  learn  the  vi  system 
and  gain  functional  use.  An  on-line  tutorial  orogram  is 
used  to  help  beginners,  since  it  is  hard  to  oecome  familiar 
with  it  on  their  own. 
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(3)  VI  does  not  Inspire  user  confidence  in  that  it  Is 
too  easy  to  accidentally  enter  some  unknown  command  string# 
and  tnere  Is  little  correlation  between  what  the  user  wants 
to  do  and  the  command(s)  that  must  be  issued. 

(4)  From  personal  use#  about  thirty  three  commands  were 
considered  to  be  generally  useful  (marked  by  *  or  **)#  and 
only  ten  of  these  accounted  for  the  greater  majority  of  all 
operations  (marked  by  **)•  The  remaining  VI  commands  were 
generally  treated  as  "window  dressing"  oy  all  but  the  most 
sophisticated  users. 

(5)  There  is  no  help  facility#  of  any  kind,  provided  by 
the  VI  system.  At  the  very  least#  an  on-line  listing  of 
commands  should  be  provided. 


APPENDIX  c:  EDIT 


EDIT  is  a  text  editor  supported  by  the  UNIX  operating 
system.  EDIT  is  a  simplified  version  of  another  UNIX 
editor  and  contains  a  minimal  set  of  operators.  It  is  line 
oriented  which  means  that  the  main  object  of  EDIT  is  a  line 
of  text  of  some  finite  length. 

EDIT  merely  supports  text  file  creation  and  modification 
operations.  The  user  inputs  text  into  a  file  by  lines, 
indicating  the  end  of  a  line  by  a  carriage  return.  a 
display  of  the  file  will  show  an  ordered  list  of  lines  as 
they  exist  in  the  file.  Ordering  of  lines  is  completely 
determined  oy  the  system  and  although  the  user  can  use  line 
numbers  as  a  reference,  the  line  number  Is  not  directly 
accessible  to  the  user  to  change  or  set.  Any  display  of 
text  by  EDIT  is  done  by  line.  Substrings  can  be  referenced 
within  a  line,  or  lines.  A  formatted  output  display  by  edit 
can  only  be  achieved  if  the  user  directly  inputs  the  desired 
format  line  oy  line,  no  processing  of  the  contents  o£  a 
line  is  done  by  EDIT, 

when  Invoiced,  EDIT  sets  aside  a  temporary  copy  of  the 
referenced  file  in  a  working  ouffer.  If  the  file  Joes  not 
already  exist  in  the  directory,  then  it  is  a  new  file  and  is 
created.  The  basic  set  of  commands  available  to  EDIT  are 
listed  in  Table  C.l. 
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Table  C«1  •  EDIT  Command  Summary 


I.  Edit  a  file 

2a  Specify  a  file 

3,  Append  lined] 

4,  Insert  lined) 

5.  insert  lined)  into  an  external  file 

6.  insert  lined)  from  an  external  file 

7.  Delete  lined) 

8.  Copy  lined) 

9,  Move  lined) 

10,  Print  line(s) 

II.  Show  line  number 

12.  List  lined) 

13.  Substitute  a  string 

14.  search  for  string 

15.  undo  last  command 

16.  wake  effect  of  command  global 

17.  Move  cursor 

-  forward 

-  backward 

18.  Quit 


Searching  for  a  line  has  the  effect  of  makina  the  found 
line  the  current  line.  Any  subsequent  editing  operations 
are  done  in  relation  to  the  current  line.  Lines  can  be 
found  and  displayed  by  line  numbers,  and  ranges  of  lines  can 
be  specified.  Lines  can  also  be  found  and  displayed  forward 
or  backward,  relative  to  the  current  line,  a  line  can  be 
found  by  any  substring  of  its  contents,  but  the  entire 
substring  must  be  contained  in  one  line.  Because  of  this 
deficiency  a  substring  may  not  be  locetable  merely  Decause 
it  exists  in  the  text  file,  when  searching  edit  will  move 
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forward  or  backward  and  will  wrap  around  the  buffer,  so  as 
to  return  to  the  starting  line  if  tne  target  object  is  not 
found. 

New  lines  can  be  appended  before  tne  current  line,  or 
inserted  after  it.  The  user  Issues  a  command  to  specify  that 
there  are  no  more  lines  to  add.  Upon  completion  the  current 
line  is  tne  last  line  added.  Additions  can  also  be  made  by 
moving  or  copying  lines  within  the  text  file.  *ovinq  can  oe 
viewed  as  a  combination  of  a  deletion  and  an  Insertion.  3y 
specifying  a  range  of  lines  to  be  changed,  they  are  deleted 
and  the  system  enters  insert  mode  for  the  user  to  add  tne 
new  lines.  Additionally,  insertions  are  possible  from  other 
text  files. 

Modifying  a  line  is  done  by  substituting  a  new  string 
for  an  already  existing  target  string  on  the  line.  It 
desired,  the  substitution  can  have  global  effect  in  that  it 
will  modify  all  occurrences  of  the  target  string  on  all 
lines. 

Deletion  is  usually  accomplished  by  indicating  tne  line, 
or  lines,  to  be  deleted,  A  search  command  can  oe  used  with 
the  deletion  operation  when  the  specific  line  numbers  are 
not  know. 

EDIT  protects  the  user  from  making  inadvertent  changes 
to  a  taxt  tile.  The  effects  of  the  last  executed  command 
that  effected  the  buffer  can  be  reversed.  Additionally,  the 
effects  of  the  editing  session  do  not  become  oermanent 
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unless  the  user  Issues  a  command  to  make  them  permanent.  At 
that  point  the  edited  copy,  which  is  in  the  butter,  replaces 
the  original  tile  in  the  directory.  Leaving  EDIT  without 
indicating  to  make  the  changes  permanent  is  like  tne  editing 
session  never  occurred. 

in  addition  to  writing  a  whole  butter  out  to  the 
directory,  subparts  can  be  written  to  another  text  file. 
This  is  done  by  specifying  the  range  of  lines  and  the  file 
to  be  written  to. 

The  EDIT  text  editor  is  very  basic  which  is  both  an 
advantage  and  a  disadvantage.  It  has  a  minimal  command  set 
and  therefore  is  easy  to  learn.  The  bigaest  prooiem  is  that 
it  is  line-oriented.  As  such,  modifications  are  done  a  line 
at  a  time,  where  each  line  is  a  separate  entity,  it  does  not 
treat  the  tile  as  a  whole,  but  as  a  disjoint  collection  of 
lines.  It  imposes  the  idea  of  line  numbers,  wnich  do  not 
exist  In  the  text  file,  in  order  to  use  the  editor.  There 
are  fewer  high  level  editing  operations  available,  as 
compared  to  current  screen-oriented  editors,  and  they  are 
limited  to  operating  on  lines  and  not  tne  text  file  as  a 
whole,  while  capaole  of  producing  satisfactory  results,  due 
to  its  line  at  a  time  limits,  the  operation  oecomes  tedious 
if  the  file  is  large,  ar.d/or  there  are  a  lot  of  small 
changes  which  must  be  done.  Given  the  advanced  features  of 
todays  line-oriented  editors,  EDIT  is  a  very  archaic  and 
frustrating  way  to  create  and  modify  a  text  file. 
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APPENDIX  0)  NROFF  -ME 


"NROFF  -ME”  is  a  text  processing  facility  for  files  that 
are  created  on  the  UNIX  operating  system.  It  was  created  by 
the  University  of  California  at  Berkeley,  and  Bell 
Laboratories,  "NROFF"  is  a  program  that  acceots  an  input 
file  prepared  by  the  user  and  outputs  a  formatted  caper  to 
the  user's  design,  "-me”  is  a  macro  package  that  enhances 
the  capabilities  of  the  "NROFF”  program  by  adding  additional 
formatting  abilities  and  commands.  The  input  file  consists 
of  the  actual  text  entered  by  the  user#  through  some  editor 
system,  and  a  series  of  embedded  NROFF  -ME  commands. 

There  Is  a  large  vocabulary  of  "reauests",  which  are 
really  dot-commands  consisting  of  a  period  followed  by  a  two 
letter  string.  The  basic  NROFF  package  supports  seventeen 
categories  of  commands,  and  has  a  total  of  eighty  seven 
commands.  The  -*E  package  adds  three  categories  and  a  total 
of  sixty  commands  for  a  grand  total  of  one  hundred  and  forty 
seven  commands.  Table  D.l  lists  the  NROFF  and  -me  command 
categories,  and  the  number  of  commands  in  eacn. 

nroff  -*£  uses  thirteen  predefined  general  variables  and 
twenty  three  predefined  read-only  variables  to  support  its 
processing  needs.  The  user  Is  provided  with  a  macro 
facility  to  define  new  commands  in  terms  of  the  basic  set  of 
commands  and  operations  on  the  variables.  This  allows  the 
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user  to  abbreviate  a  fairly  long  command  stream  into  a 
single  command. 


Table  0.1  -  nroff  and  -me  Commands. 


COMMANDS 


COMMAND  CATEGORY 


NROFF 


-*E 


1.  Font  6  Character  Size  Control 

7 

9 

2.  Pace  Control 

7 

0 

3.  Text  Filling.  Adjusting  &  Centering 

6 

0 

4.  Displays 

0 

22 

5.  Vertical  spacing 

7 

0 

6.  Line  Length  &  indenting 

3 

0 

7.  Paragraphing 

0 

4 

8.  Macros.  Strings.  Diversions,  &  Traps 

13 

0 

9.  Number  Registers 

3 

0 

10.  Tabs',  Leaders,  &  Fields 

4 

0 

11.  InoutOutout  Conventions 

9 

0 

12.  Hyonenation 

4 

0 

13.  Titles 

3 

13 

14.  Headlnas 

0 

b 

15.  Line  Numbering 

2 

0 

16,  Conditional  Input 

8 

0 

17.  Environment  Switching 

1 

0 

18.  Standard  Input  Insertions 

2 

0 

19,  InputOutput  File  Switching 

3 

0 

20.  Miscellaneous 

5 

6 

TOTAL 

ef 

60 

nroff  -me  is  a  good  word  processing  system  and  It  can 
produce  some  complex  formatting  actions.  However,  it  does 
suffer  from  some  drawbacks. 

(1)  Since  the  file  is  first  created  by  the  text  editor 
and  then  run  by  NROFF ,  the  user  has  a  significant  delay  in 
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determining  If  the  deeired  format  was  achieved. 

(2)  In  addition  to  depending  on  the  text  editor,  NROFF 
aust  depend  on  other  programs  to  preprocess  the  text  file 
before  NROFF  ean  handle  it  for  specialized  reauests.  Two 
examples  of  preprocessors  are  packages  to  handle  tables  and 
complex  equation  symbolooy,  while  enhancing  npoff  -he's 
capabilities,  they  add  more  categories  and  commands,  and 
increase  the  amount  of  time  necessary  for  tne  user  to  see 
the  aetual  results  of  commands. 

(3)  The  user  manual  for  the  NROFF  pacxaae  is  not 

presented  in  sufficient  detail  to  completely  understand  the 

effect,  or  use,  of  all  commands.  Zt  appears  that  the  user 

* 

is  supposed  to  have  a  basic  understandina  of  the  system 
before  reading  the  manuals  1 

(4)  The  command  vocabulary  is  fairly  large  and  tnev  are 
not  easy  to  remember.  Rased  on  personal  use,  only  about 
twenty  percent  of  the  vocabulary  Is  generally  useful  and 
therefore  remembered.  Table  D.2  presents  a  simplified 
listing  of  tne  most  used  commands. 
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Table  0.2  •  Baric  Commands  fcROFF  -ME 


1.  Page  length 

2.  Line  spacing 

3.  Line  lepgtn 

4.  Page  headers 

5.  Indent 

-  permanent 

-  temporary 

6.  Begin  next  paqe 

7.  Need  *  lines 

8.  Insert  #  blank  lines 

9.  Center  tne  next  »  lines 

10.  Break 

11.  Define  a  macro 

12.  FI 11/No-f 111 

13.  Hyphenate/No-hyphenate 

14.  Underline 

15.  Section/Chapter  headings 

16.  Quotations 

17.  Footnotes 

18.  Keep  an  index 

19.  Start  paragraph 

-  basic 

•  left  adjusted 

-  oodv  indented 

-  numbered 

20.  start  display 

-  list 

-  block 

-  floating  block 

-  delayed  text 

21.  Table  handler  * 

-  definition 

-  start 

-  body 

-  end 

22.  Eauation  definition 

23.  Multiple  column  format 

24.  Default  paper  formats 

-  thesis 

25.  Control  constructs 

-  read  special  variables 

-  change  special  register 

-  conditional  formatting 

*  part  of  Table  preprocessor 
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APPENDIX  E:  DBASE  II 


DBASE  II  Is  a  relational  database  system  created  by 
Ashton-Tate  of  Los  Angeles,  California  for  microcomputer 
systems.  For  this  review,  the  CP/M  version  of  DBASE  II  was 
used,  wnere  the  DBASE  II  program  is  an  executable  "command 
file"  residing  In  the  system. 

The  DBASE  II  system  utilizes  several  different  file 
types*  database,  report  form,  command,  index,  memory,  and 
text.  Each  file  type  has  a  specific  purpose  that  is 
Identifiable  by  its  type  name.  "Report  form"  files  store  the 
information,  specified  by  tne  user,  for  describing  the 
format  (headings,  fields,  totals,  subtotals,  contents,  etc.) 
in  which  a  "database"  file  is  to  be  output.  "Command"  files 
contain  a  sequence  of  DBASE  II  statements,  commands,  and 
control  structures  necessary  to  create  a  user  defined  view. 
"Index"  files  are  a  list  of  Pointers  to  a  specific 
"database"  file,  "Memory"  files  contain  tne  values  of 
memory  variables  and  constants  saved  previously  bv  the  user. 
"Text"  files  are  collections  of  ASCII  characters  for  input 
Into  a  "database"  file,  or  created  by  output  from  a 
"database”  file,  DBASE  II  cannot  directly  use  "text"  files. 
Most  of  the  ~~FTTW~-are~ et-oTAd  in  what  is  known  as  Standard 
Oata  Format  (3DF),  and  they  can  be  used  direetly  by  any 
other  program  that  uses  SDF  flies.  Additionally,  any  text 
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flits  In  SDP  etn  bt  ustd  by  Che  DBASE  II  system.  The  file 
is  the  largest  data  object  supported  by  obase  II  which 
creates,  deletes,  or  modifies  the  current  flle(s).  a 
database  file  Is  brought  Into  reference  by  user 
specification,  and  a  maximum  of  two  database  flies  can  be 
"open"  at  one  time. 

DBASE  IX  can  be  used  Interactively  or  can  be  programmed 
to  create  a  view  of  the  database  to  support  recurring 
applications.  Regardless  of  method,  DBASE  II  provides  the 
user  with  the  same  basic  high-level  data  definition  (DDL) 
and  data  manipulation  (DHL)  language.  An  English  HKe 
command  language  wltn  a  very  regular  syntax  Is  a  user 
friendly  feature  of  DBASE  II.  Tne  commands  are  very 
powerful  In  that  their  operands  and  results  are  typically 
database  files.  The  command  structure  Is  usually  presented 
in  the  following  form: 

COWHAND  (SCOPE)  (CONDITION) 

The  scope  modifier  designates  the  number  of  records  to 
be  selected  In  response  to  the  specific  command.  The 
condition  modifier  specifies  •  conditional  statement  that 
the  record's  field  values  must  satisfy  in  order  for  the 
record  to  be  Included  in  the  final  result.  Table  E.i 
provides  a  listing  of  the  basic  DBASE  II  commands,  with 
duplicate  commands  having  been  factored  out. 
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Table  E, 1  -  DBASE  II  Basie  Commands 


1.  Display  an  expression  on  the  screen 

2.  Format  screen  or  printer  output 

3.  Input  a  character  strina 

4.  Input  a  string  to  a  memory  variable 

5.  wait  for  user  input 

6.  List  the  records  in  a  database 

7.  Olsolay  data  from  a  database 

8.  Olsolay  the  structure  of  a  database 

9.  Rename  a  file 

10.  Erase  a  file 

11.  Generate  a  report 

12.  Execute  a  "command"  file 

13.  Return  from  a  "command"  file 

14.  Display  the  contents  of  the  memory  varlaoies 

15.  Store  a  value  in  a  memory  variable 

16.  save  memory  variables  to  a  file 

17.  Restore  memory  variables  from  a  file 

18.  select  a  specific  database  for  use 

19.  Set  specific  DBASE  II  parameters 

20.  Abort  a  command 


21.  Create  a  nee  database 

22.  Edit  a  database 

23.  Modify  a  database's  structure,  or  the 

contents  of  fields  in  selected  records 

24.  Update  a  database  from  another  database 

25.  Add  data  from  a  text  file  to  a  database 

26.  Copy  data  from  a  database  to  a  text  file 

27.  Insert  record(s)  into  a  database 

28.  Delete  recordCsl  from  a  database 

29.  unmark  records  marked  for  deletion 

30.  Locate  a  record  based  on  key  value, 

or  condition 

3t,  Goto  a  specified  record 

32.  move  forward  or  backward  in  a  database 

33.  Index  a  database 

34.  Sort  a  database  based  on  a  field 

35.  Perform  JOIN  operation  on  two  databases 


36.  Count  the  number  of  records 

37,  Sum  a  field  or  subfield  in  a  database 
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Default  ordering  for  records  in  a  database  tile  is  the 
sequence  in  which  the  records  are  entered.  Ordering  can  oe 
altered  by  inserting  records  into  specific  parts  of  the 
database,  and  by  sorting  or  indexing  the  database.  Xn  the 
default  order,  the  "database"  file  does  not  contain  a 
recognised  Key. 

By  sorting  or  Indexing  a  "database"  file.  Keys  are 
defined  and  the  search  time  required  to  locate  a  record  is 
reduced.  Multiple  indexing  be  done  for  the  same  database, 
but  based  on  different  Keys.  Sorting  produces  a  new 
"database"  file,  which  is  a  copy  of  the  original  database, 
only  it  is  sorted.  An  "indexed"  file  is  a  virtual  file  of 
pointers  to  the  original  "database"  file.  whereas  lookup 
speed  can  be  enhanced  by  Indexing  a  database,  there  is 
overhead  incurred  in  maintenance  of  the  "index"  file. 
Changes  made  to  the  original  database  file  are  not  reflected 
In  tne  new  sorted  "database"  or  "index"  file.  The  oriainai 
database  must  be  sorted  or  indexed  after  each  change  in 
order  to  remain  current. 

The  data  definition  language  allows  the  user  to  define 
the  organization  of  the  data  in  a  new  database  file  oy 
specifying  the  name  of  the  database,  and  giving  information 
on  each  of  its  fields  (name.  type,  width,  decimal  places). 
The  structure  of  e  new  database  file  can  also  be  copied  from 
that  of  another  database  file.  Additionally,  new  structures 
can  be  created  as  the  result  of  using  the  join  operator 
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provided  by  the  DBASE  XX  system.  At  any  time,  the  structure 
end/or  contents  of  a  file  can  be  displayed  or  output.  The 
structure  of  a  database  file  can  also  be  modified  at  a  later 
time,  but  presents  seme  problems  In  that  all  records 
currently  In  the  database  file  are  destroyed. 

Besides  uslno  DBASE  XI  interactively,  it  can  be 
programmed  In  its  own  language  through  the  use  of  "command” 
files.  The  DAL  statements  are  embedded  in  the  file  and 
iterative  execution  of  DWL  statements  are  controlled  by  a 
set  of  DBASE  XI  control  structures  Clf-Then,  If-Then-Else, 
Goto,  and  Do-while).  "Command"  files  tend  to  make  extensive 
use  of  memory  variables  and  input/output  functions  which  are 
also  extensively  supported  by  OBASE  II.  To  create  a  user 
view  the  deslgner/proarammer  win  edit  a  "command"  filets) 
to  contain  the  correct  DBASE  II  statements,  commanas,  and 
control  structures  to  manipulate  the  oroper  "database" 
files.  The  capabilities  and  limitations  of  any  view  is 
dependent  on  the  desion  of  tne  "command"  filets). 

The  reason  for  the  qreat  popularity  of  DBASE  II  is  that 
it  Is  a  very  easy  database  management  system  to  learn  and 
use.  Its  Enqilsh-like  command  language  is  natural  and  user 
friendly.  Although  the  command  set  is  rather  extensive,  the 
command  names  accurately  describe  their  action  and  use  a 
regular  syntax  so  they  are  easy  to  remember.  The 
interactive  nature  and  full  screen  display  orientation  makes 
user  interaction  simple  and  direct.  with  Its  set  of 
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predefined  functions#  input/output  commends,  "commend” 
files#  end  programalng  constructs  it  is  easy  to  create  views 
tor  eleost  any  application.  *  DBASE  IX  is  a  powerful 
relational  database  system  yet  it  is  obvious  that  the 
designers  gave  ouch  thouqht  to  Keeping  it  simple  end  did  not 
introduce  complexity  for  its  own  same.  However,  there  ere  a 
couple  of  problems  with  DBASE  IX  which  ere  worth  mentioning, 
and  they  are  all  probaoly  due  to  the  justified  emphasis  on 
simplicity. 

(1)  At  any  one  time,  a  maximum  of  two  databases  can  oe 
in  reference.  This  limitation  requires  tnat  databases  be 
explicitly  brought  into  and  out  of  use.  It  would  help  if 
there  was  another  method,  besides  using  a  "command"  file, 
for  performing  operations  on  multiple  taoles. 

(2)  In  modifying  the  structure  of  a  database  the 
contents  are  deleted.  This  requires  that  the  database  oe 
explicitly  saved  to  an  external  database  and  then  be 
recopled  bade  after  structure  modification.  It  is  an 
inconvenience,  to  say  the  least. 

(3)  The  only  relational  operation  directly  provided  by 
the  system  is  the  JOIN  command.  Xt  would  greatly  enhance  the 
capability  of  the  system  to  provide  more  of  tne  operators. 

(4)  The  display  structure  is  e  little  bit  too  rigid, 
and  the  user  does  not  nave  much  direct  control,  sort  of 
writing  e  "command"  file,  to  effect  tne  output  format. 
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APPENDIX  Fi  SEQUXTUR 


SEQUITUR  Is  a  relations!  database  system  designed  by  the 
Pacific  software  Manufacturing  Company  of  Berkeley, 
California. 

SEQUITUR  sees  a  database  as  a  collection  of  named 
tables,  each  of  which  contains  some  kind  of  data  related  to 
the  subject  of  the  database.  Eaeh  database  has  a  set  of 
system  tables.  The  "Column"  table  lists  the  name,  type, 
size,  and  display  format  of  all  columns  authorized  for  use 
in  the  database's  tables.  The  "Table"  table  lists  the  names 
of  the  columns  that  are  included  in  each  of  the  database's 
tables.  Together  the  "Column"  and  "Table"  tables  act  as 
part  of  a  data  dictionary  system  for  the  database. 

SEQUXTUR  has  a  fairly  large  command  vocabulary  of  over 
sixty  seven  commands.  There  are  twenty  five  basic  commands, 
forty  two  screen  editor  commands,  and  more  formed  by 
combinations  of  the  previous  commands.  A  multilevel  "Helo" 
facility  is  used  to  support  the  user. 

SEQUITUR  offers  four  kinds  of  help.  There  are  status 
lines  at  tne  top  of  the  screen.  An  "edit  card"  display  can 
be  called  oy  tne  user  In  order  to  see  a  comprehensive  list 
of  cursor  object  and  motion  keys,  and  eseaoe  operations. 
The  "help”  command  summons  an  on-line  manual,  that  is  oreset 
py  the  user  to  provide  no,  medium,  or  maximum  neio.  Lastly, 
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there  are  situational  help  prompts  that  occur  during 


the 


command  process. 


Table  F,1  -  SEQUITUR  Basic  Commands. 


1.  CHOOSE  (database) 

2.  CREATE  (database) 

3.  ADD  to  (table) 

♦,  EDIT  (table) 

5,  SHOW  (table) 

6,  PRINT  (table) 

7,  REPORT  generator 
9,  FORMS  generator 

9.  SELECT  from  (table) 

10.  MANUAL  select 

11.  JOIN  (tables) 

12.  SORT  (tables)  * 

13.  UNION  * 

14.  INTERSECTION  * 


15.  DIFFERENCE  * 

16.  UNIQUE  roes  * 

17.  DUPLICATE  rows  * 

18.  COPY 

19.  APPEND 

20.  REMOVE  TOWS 

21.  RENAME  column 


22.  COMPACT  base 

23.  DUMP  to  (file) 

24.  LOAD  from  (file) 

25.  HELP  from  manual 

26.  EXIT 


*  «  Member  of  SEQUITUR'*  "set"  commands. 


The  twenty  five  basic  commands  cover  the 
operational  capabilities  of  the  SEQUITUR  system 
commands  are  presented  to  the  user  in  the  form  of  a 


major 
The 
menu , 
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there  are  situational  help  prompts  that  occur  during  the 
command  process. 


Taola  F,i  -  SCQUZTUR  Basic  commands. 


1.  choose  (database) 

2.  CREATE  (database) 

3.  ADD  to  (table) 

4.  EDIT  (table) 

5.  SHOW  (taole) 

6.  PRINT  (table) 

7.  REPORT  qenerator 

8.  forms  generator 

9.  SELECT  from  (table) 

10.  MANUAL  select 

11.  JOIN  (tables) 

12.  SORT  (tables)  * 

13.  UNION  * 

14.  INTERSECTION  * 


* 


15.  DIFFERENCE  * 

16.  UNIQUE  rows  * 

17.  DUPLICATE  rows  * 

18.  COPY 

19.  APPEND 

20.  REMOVE  rows 

21.  RENAME  column 

22.  COMPACT  base 

23.  DUMP  to  (file) 

24.  LOAD  from  (file) 

25.  HELP  from  manual 

26.  EXIT 


*  «  Member  of  SEQUlTUR's  "set"  commands. 


The 

twenty  five 

easle 

commands  cover 

the 

major 

operational 

capabilities 

Of  the  SEQUITUR 

system 

,  The 

commands 

are 

presented 

to  the 

user  in  tne  form 

of  a 

menu. 
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and  one*  a  enoiet  Is  made  SCOUZTUR  enters  the  display  node 
necessary  to  support  that  choice.  laple  F.l  lists  the  basic 
commands,  plus  the  command  for  exiting  from  SEQUITUR. 

The  SEGUITUR  display  modes  are  organized  as  "tables",  or 
"pages".  The  table  mode  Is  similar  to  the  approach  taken  by 
the  "Ouery-by-Example"  system  (QBE),  and  presents  the  data 
In  columns  and  rows  with  vertical  lines  separatlna  the 
columns  and  Indicators  for  new  rows.  Alternatively,  the 
page  mode  presents  the  data  one  row  at  a  time,  with  tne 
column  headings  listed  vertically.  The  user  has  the  ability 
to  flip  back  and  forth  between  the  two  display  modes  at 
will. 


Table  F.2  -  SEQUITUR  Cursor  Object  6  motion  Commands, 


1,  Move  cursor  up  one  line 

2,  Move  cursor  down  one  line 

3,  Move  cursor  left  one  object 

4,  move  cursor  to  next  object 

5,  Move  cursor  to  beginning  of  object 

6,  Move  cursor  to  previous  word 

7,  Move  cursor  to  end  of  current  object 

8,  Move  cursor  to  next  word 


9, 

Object 

3 

word 

10. 

Object 

3 

line 

11. 

Object 

3 

sentence 

12. 

Object 

3 

oaragraph 

13. 

Object 

3 

view 

14. 

Object 

3 

page  or  screen 

15. 

Object 

S 

column 

16. 

Object 

3 

row 

17. 

Object 

3 

one  character 

*n 
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One*  In  «  desired  display  mode  the  user  must  make  use  of 
the  editor  commands  to  sake  changes  to  the  table.  All  editor 
commands  are  single  keys  contained  with  tne  <Control>, 
<Esc*pe>,  or  <Tee>  keys.  Table  F.2  provides  a  list  of  the 
cursor  object  and  motion  commands  available.  Most 
operations  require  two  commands  since  the  object  must  be 
specified  first,  and  then  the  actual  operation. 


Table  F.3  -  SEQUITUR  Screen  Editor  Commands. 


1.  Delete  left  portion  of  object 

2.  Delete  entire  object 

3.  Delete  right  portion  of  object 

4.  Flips  "insert"  toggle 

5.  Shows  rows  marked  for  deletion 

6.  Flip  "page-taole"  display  style 

7.  Goto  »-tn  object 

8.  Goto  last  ooject 

9.  Restores  more  recent  version  of  row 

10.  Display  earlier  version  of  row 

11.  Executes  a  command 

12.  Search  forward  for  column  entry 

13.  Search  backwards  for  column  entry 

14.  Edit  card  display 


The  screen  editor  commands  are  used  to  make  actual 
changes  (additions,  modifications,  or  deletions)  to  the 
displayed  table  on  the  screen.  Table  F.3  lists  these 
commands  which  are  used  in  conjunction  with  the  cursor 
objeet  and  movement  commands  listed  previously. 


109 


Additionally  there  are  a  number  of  miscellaneous 
commands  tnat  are  provided  to  eld  the  user.  These  are  listed 
in  Table  F.4. 

Table  P.4  -  Additional  SEQUITUR  Commands 

I7~~Get~Edlt~HeuT  *  ’****** 

2.  Scroll  Forward 

3.  Scroll  Backwards 

4.  interrupt  Present  Ooeratlon 

5.  Lock/unloc*  Cursor  Object 


There  are  an  abundance  of  table  tyoes  In  SEQUITUR. 
•virtual"  tables  consist  of  pointers  to  data  In  a  "base" 
table(s),  and  are  formed  by  conducting  relational  operations 
(e.g.  JOIN)  on  the  base  table(s).  Virtual  taoles  are 
permanent  additions  to  the  database.  All  operations 
conducted  on  the  virtual  table  effect  the  base  table,  but 
not  all  operations  on  the  base  table  *111  reflected  in  the 
virtual  table. 

"Slice"  tables  consist  of  the  data  from  a  "home"  taoie, 
and  are  formed  by  restricting  or  rearranging  the  columns  in 
the  home  table.  Actually,  slice  tables  are  just  alternate 
ways  of  viewing  the  same  home  table.  All  operations 
conducted  on  tne  slice  table  effect  the  home  table,  and  all 
ooerations  on  the  home  table  etfeet  the  slice  table. 
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"Template"  tables  <r«  used  to  store  control  information 
on  the  op«retlon(«)  (SELECT,  SORT,  UNION,  DUPLICATE,  unique, 
INTERSECTION,  end  DIFFERENCE!  desired  to  be  performed  on  a 
set  of  "base”  tables,  The  user  specifies  once  the  seouence 
of  operations  to  be  performed,  and  each  time  tnat  result  Is 
desired  ene  appropriate  template  table  is  called  to  create 
tne  desired  virtual  table. 

SE3UITUR  provides  several  methods  of  outputting  data  to 
tne  user: 

(1)  There  is  the  "print”  command  which  prompts  the  user 
to  specify  heading,  page  length,  margins,  oaqe  number,  date, 
column/row  divider  symbol,  ate.  for  either  a  "table"  or 
"page"  style  output.  The  entire  table  Is  then  output,  one 
record  at  a  time,  in  tne  specified  format. 

(2)  Thera  Is  tne  "form  generator".  The  user  creates  a 
form  letter  or  document  by  making  an  entry  in  the  "forms" 
taole  in  either  "page"  or  "table"  style,  and  answering 
several  system  prompts  as  to  page  size,  width,  margins.  The 
form  generator  is  intended  for  letter  tyoe  generation  since 
it  only  allows  one  text  field  in  the  form.  All  other  entries 
are  pulled  from  an  aopropriate  table  and  tne  "form"  repeated 
for  each  row  In  tnat  table, 

(3)  There  is  tne  "report  generator".  The  user  creates  a 
report  table  that  is  associated  with  a  known  data  table.  The 
report  table  specifies  wnlch  data  table  columns  are  to  be 
used,  now  they  are  positioned,  what  name  they  have  on  tne 
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form,  Allotted  width,  and  alignment.  Again,  the  user  must 
specify  formatting  items  lixe  page  length,  line  length, 
margins,  delimiters,  and  other  related  items.  The  individual 
columns  in  the  report  taole  can  be  marked  for  sorting, 
grouping,  and/or  arithmetic  processing.  It  arithmetic 
processing  is  opted  for,  then  another  taoie,  the  "function" 
table  is  created  to  record  what  is  to  be  done  to  each  column 
•  total,  minimum,  maximum,  average,  or  count. 

Based  on  a  very  short  f amiliarlzatlon  experience  with 
SEQUITup  there  is  no  doubt  that  it  is  a  powerful  and 
comoiete  relational  DBWS.  However,  it  Is  not  as  user 
friendly  as  Its  advertisements  would  lead  you  to  believe. 
Some  of  the  problems  encountered  were: 

(1)  Too-  many  commands  to  remember.  This  Increased 
learning  time  and  added  to  the  confusion.  Too  many  of  tne 
commands  were  just  window  dressing  in  that  tnelr  effect 
could  have  oe  done  using  other  commands.  (Like  the  "Object 

extra  cursor  movement  and  deletion  commands.)  while 
using  keys  as  commands  leads  to  faster  command  Input,  it 
makes  things  more  difficult  whan  tnere  are  so  many  commands 
the  symbol  on  the  key  has  little  or  no  relation  to  its 
effect. 

(2)  The  structure  of  the  user  Interface  was  unwieldy.  It 
was  easy  to  get  lost  and  difficult  to  recover  to  a  known 
location.  Operations  that  worked  under  one  condition  did 
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not  work  In  another,  or  produced  completely  different  and 
unexpected  results,  (a. 4.  in  some  Instances  the  "execute" 
command  will  return  you  to  the  main  menu,  in  others  it  was 
ionored  or  treated  as  a  mistake.) 

(3)  There  were  too  many  types  of  tables,  ways  of  using 
tables,  editing  tables,  and  creating  relations  between 
tables.  The  user  is  being  swamped  with  a  level  of  detail 
that  is  oetter  left  to  the  system,  rt  seems  that  SEQUiTUR 
was  created  with  simplicity  and  user  support  being  lesser 
considerations  to  system  sophistication. 
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APPENDIX  Cs  VISICALC 


VZSXCALC  Is  an  electronic  spreadsheet  prooram  created  by 
Software  Arts,  Inc,  of  Cambridge,  Massachusetts  and  marketed 
by  Personal  Software  Inc.  of  Sunnyvale#  CA,  its  purpose  Is 
to  allow  the  user  to  easily  model  a  wide  range  of  numerical 
prooiems  In  a  standard  tabular  format  by  replacing  tne 
user's  pencil#  calculator#  and  scratchpad. 

The  screen  Is  divided  into  a  grid  of  columns  ahd  rows 
that  form  addressable  (column#  row)  entry  positions.  The 
columns,  which  run  across  the  top  of  the  grid,  are  lettered 
starting  with  "A"  and  the  rows,  which  run  down  the  side,  are 
numbered  starting  with  "l".  Each  entry  position  is  an 
inoeoendent  entity,  and  can  contain  a  character  string,  a 
numeric  value,  or  a  function  that  must  ee  calculated.  Entry 
positions  that  contain  functions  are  recalculated  by 
VISICALC  each  time  certain  conditions  are  met.  The  functions 
will  specify  values  in  terms  of  constants,  operators,  and 
the  values  of  other  entry  positions. 

The  sereen  Is  used  es  e  "window"  into  the  spreadsheet 
and  Is  modifiable  by  the  user.  The  user  is  given  numerous 
commands#  see  Teble  6,1#  with  whleh  to  alter  tne  display 
format  of  the  sereen. 


Table  G,  l  -  VISICALC  Display  Commands 


1.  Clear  Spread  Sheet 

2.  Set  Global  Olsplay  Format  To; 

•  Integer 

•  Dollars  &  Cents 

-  Left/Right  Justified 

-  Graph 

3.  Set  Entry  Display  Format  To; 

-  integer 

-  Collars  &  Cents 

-  left/Riaht  Justified 

-  Graph 

4.  Reset  Entry  To  Global  Display  Format 

5.  Set  Column  width  Within  A  window 

6.  Set  Order  Of  Recalculation; 

•  Column  wise 

-  Row  wise 

7.  set  Recalculation; 

-  Automatic 

•  Manual 

8.  Move  An  Entire  Row  or  Column 

9.  window  Control; 

•  Spilt  Screen  Horizontal 

•  Split  Screen  vertical 

•  Single  window 

10.  window  Synchronization; 

-  Synchronized 

•  Unsynchronized 


The  window  can  be  "split"  into  two  halves  so  as  to  lno< 
into  nonadjoining  areas  of  the  spread-sheet  simultaneously. 
The  two  windows  can  be  "synchronized"  so  they  move  toaet.ner, 
or  unsynchronized  so  movement  is  independent.  Disolay 
format  may  be  globally  set  for  the  screen  as  a  whole,  or 
individual  entry  oositlons  can  be  assigned  their  own  format. 
Column  width  is  variable  from  3  to  37,  out  columns  in  the 
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same  window  must  have  the  same  width.  The  value  of  eaeh 
entry  position  Is  calculated  by  "column  order"  (At,  A2,  ..., 
An,  Bl,  B2,  Bn,  Cl,  etc.)  unless  the  user  chances  the 
recalculation  order  to  "row  order"  (At,  Bl,  ...,  nl,  A2,  &2, 
...,  n2,  C2,  etc*).  By  default  VISICALC  starts  In 
"automatic"  recalculation  mode  where  the  value  of  all  entry 
positions  are  recalculated  each  time  an  entry  is  chanced.  As 
this  can  significantly  slow  down  uhe  model  when  lame  arlds 
and/or  complicated  numerical  expressions  are  used,  the  user 
can  enter  "manual"  recalculation,  mode  where  a  command  must 
be  Issued  to  cause  recalculation  to  occur. 

VISICALC  provides  a  command-line  oriented  editor  that 
enters,  modifies,  or  deletes  data  in  a  referenced  entry 
oositlon(s).  A  cursor  is  provided  on  the  grid  to  indicate 
the  current  entry  position  referenced  by  visiCAtC.  There 
are  screen  commands  to  allow  the  user  to  scroll  across  tne 
grid  or  to  move  to  an  exact  (row,  column)  entry  Dosltlon. 
If  needed,  tne  numeric  processing  capability  of  VISICALC  can 
be  used  lltce  a  calculator  to  support  the  user's 
computational  needs.  A  powerful  capability  of  visicalc  is 
the  replicate  command.  This  allows  the  user  to  defire  an 
entry  once,  and  then  have  it  entered  in  a  ranae  of 
successive  column  or  row  entry  positions.  Additionally,  the 
user  can  specify  If  the  original  entry  Is  to  be  replicated 
exactly,  or  should  any  references  to  other  entry  positions 
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be  updated  at  each  new  position  '  to  ta*e  into  account 
relative  position  on  the  spreadsheet. 


Table  G.2  -  VISICALC  Cursor  Movement  &  Entry  Commands. 


11.  Move  Cursor  Riche  Or  Up 

12.  Move  Cursor  Left  or  Down 

13.  Change  Cursor  Direction; 

-  Up/Down 

-  elcht/Le£t 

14.  Move  Cursor  To  T ne  other  window 

15.  Move  Cursor  To  a  Specific  Entry  Position 


Id.  Abort  Last  Command 

17,  Set  An  Entry  Position  To  Blanic 

18.  Delete  An  Entire  Row  Or  Column 
IP.  Inset  A  vew  Row  Or  Column 

20.  Replicate  An  Entry 

21.  Set  Title  Areas; 

-  Horizontal  Title 

-  vertical  Title 

-  No  Title 

22.  Repeat  a  label  Entry 

23.  '"axe  An  Immediate  Numerical  Calculation 

24.  Enter  a  Label  In  An  Entry  Position 

25.  Enter  a  Value  In  An  Entry  Position 
25.  Save  A  Copy  Of  The  Spread-Sheet 


Since  VISICALC  is  a  numerical  modeling  tool  it  has  a 
series  of  arithmetic  and  aggregate  functions  that  it 
supports.  Table  G.3  provides  a  listing,  VISICALC  has  been 
designed  to  store  numbers  in  decimal  format,  not  binary,  and 
maintains  them  with  uo  to  eleven  significant  digits  or 


decimal  olaces. 


Table  G.3  -  VXSXCALC  Arithmetic  6  Aggregate  Functions 


a.  Addition 

b.  subtraction 

c.  Multiplication 

d.  Division 

e.  exponentiation 

f.  Calculate  The  Sum  Of  A  Pang#  Of  values 

g.  Calculate  The  Minimum  In  A  Ranoe  Of  values 

h.  Calculate  The  Maximum  Xn  A  Range  Of  Values 

l.  Count  The  Number  Of  Entries  Xn  A  List 

j.  Calculate  The  Average  Of  A  Ranoe  Of  values 
X.  Calculate  The  Net-Present-Value  Of  A 
Range  Of  Values 

1*  Perform  A  Lookup  Operation 

m.  PX  (3.1415926536) 

n.  Calculate  The  Absolute  Value 

o.  Calculate  The  integer  Portion  Of  A  value 

p.  souare  Root 

g.  Logarithms,  Base  2 

r.  Logarithms,  Base  10 

s.  Trigonometric  Functions  (Sin,  Cos,  Tan,  Asln, 

Acos,  Atan) 


VISTCALC  makes  use  of  dynamic  memory  allocation  so  the 
actual  dimensions  of  the  spread-sneet  deoend  on  the  amount 
of  memory  available  and  tne  complexity  of  the  entries  made 
by  the  user.  The  user  does  not  have  to  worry  about  memory 
allocation  sinee  VXSXCALC  takes  responsibility  for  its  use 
and  efficiency.  As  entries  shrink,  or  are  deleted,  visicalc 
reclaims  the  extra  memory  space.  The  user  is  shown  how  much 
memory  remains  and  a  warning  prompt  oceurs  when  memory  space 
is  nearly  exhausted. 
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Por  «  permanent  eopy  of  the  contents  of  the  spread  sheet 
the  user  nay  send  the  output  to  a  printer,  A  subpart  of  the 
total  spread-sheet  nay  be  sent  by  designating  the  lower 
right  corner  to  be  printed. 

V1SXCALC  is  a  powerful  and  fairly  simple  modeling  tool 
whose  advantages  seem  to  easily  outweigh  the  disadvantages. 
The  command  vocabulary  is  low  (26  commands,  19  functions) 
and  the  greater  majority  are  actually  useful  and  not  just 
window  dressing.  The  user  manual  is  well  written  and  easily 
understood,  but  is  fairly  lonq.  VZSICALC  supports  a  Known 
human  weakness  (small/fast  short  term  memory,  large/slow 
Iona  term  memory,  and  slow  calculation  speed)  by  remembering 
the  details  of  a  commonly  reoccurring  user  proolem  (tne 
situation  to  be  modeled),  limiting  tne  user  to  orovidlno  a 
smaller  and  more  select  set  of  initial  inputs,  ano 
performing  the  computations  in  a  faster,  more  reliable,  and 
repeatable  manner.  However  it  does  have  some  orooiems: 

Cl)  Command  strings  and  their  effect  must  be  memorized 
since  there  is  little  relation  to  the  strino  and  the  effect. 
Wenus  provided  by  the  system  are  very  poor,  and  require  you 
to  already  know  the  meaning  of  tne  commend  string. 

(2)  A  basic  understanding  of  VISXCALC  and  a  hiqn  deqree 
of  operational  capability  can  be  obtained,  in  a  fairly  short 
time,  by  reading  only  the  first  third  of  the  user  manual. 
However,  to  gain  maximum  use  of  the  system  requires  a 


ilgnlflct.it  amount  of  time  and  effort  to  read  the  entire 
viler  manual  and  experiment  with  the  operations.  Some  nice  to 
*now  features  that  have  a  major  effect  on  model  validity 
(e.g.  recalculation  order)  are  discussed  at  the  end  of  the 
user  manual  and  might  oe  easily  missed. 
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APPENDIX  Hj  ZIP 


The  relational  data  bast  management  system  "DBASE  II", 
described  In  Appendix  CD),  contains  a  set  of  commands  which, 
■hen  embedded  In  a  "command"  file,  define  the  output  format 
used  to  generate  the  display  on  the  screen,  or  output  to  the 
printer.  In  addition  to  generating  the  display  form,  the 
commands  also  direct  the  03ASE  II  system  to  either  determine 
the  values  of  the  entries  from  a  record  in  tne  referenced 
database,  or  from  memory  variables,  if  the  inout  device  is 
tne  screen/keyboard,  DBASE  II  may  retrieve  a  user  entered 
value  from  tne  screen  and  store  It  in  a  field  of  a  dataoase 


record. 

or  In 

a 

memory 

variable. 

These 

form  definition 

commands 

can 

also  be 

put  into  a 

new 

tyoe  of  file,  the 

"format" 

file. 

by 

ZIP. 

In  this  case 

the 

format,  contained 

In  the  "format"  file.  Is  used  as  an  display  overlay 
prompt  the  user  to  chanae  data  values  in  an  existlnq  record 
in  a  "database"  file. 

ZIP  Is  a  CP/m  program  used  to  generate,  or  modify,  a 
OBASE  II  "command"  or  "format"  file.  It  Is  a  powerful  tool 
in  the  sense  that  the  user  is  not  required  to  know  the 
details  of  the  DBASE  II  form  generation  capability 
("command"  files,  and  display  commands),  ZIP  presents  the 
user  with  a  blank  screen  and  an  on-screen  editor,  vhicn 
supports  several  levels  of  cursor  movement  and  formattino 
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eoaaands,  to  help  In  the  form  design.  Table  H.i  lists  the 
ZIP  editor  commands. 


Table  H.I  -  ZIP  Editor  Commands. 


1.  Screen  commands 

-  top 

-  bottom 

-  next 

-  previous 

-  first 

-  last 

2.  Middle  of  line 

3.  Insert  a  space 

4.  Add  a  line 

5.  Delete 

-  character 

•  line 

6.  Draw/Erase  horizontal  line 

7.  Draw/Erase  vertical  line 

8.  Erase/Save  work  file 

9.  Insert  DBASE  II  command  expression 

10.  Change  variable 

-  vertical  marker 

-  horizontal  marker 

-  tab  spacing 

•  margin 

•  oage  length 

11.  Quit 


The  cursor  can  be  moved  to  any  Position  on  the  blank  screen 
•here  tne  user  *111  enter  the  information  reauired  by  the 
ZIP  program,  information  is  conveniently  limited  to  literal 
strings,  memory  variables,  record  field  values,  and  fetching 
a  value  from  the  screen  and  storing  it  into  a  record  field 
or  memory  variable.  Interspersed  Between  these  ZIP 
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formatting  commands  may  be  DBASE  xz  executable  commands  if 


the  file  type  Is  "command”.  There  are  special  purpose 
commands  to  draw,  or  undraw,  vertical  and  horizontal  lines 
on  the  form. 

The  ZIP  program  may  be  viewed  as  a  translator  between 
the  screen  design  made  by  the  user  and  the  ooeratlons  of 
DBASE  II.  The  screen  contents  associated  with  each  screen 
position  are  translated  into  a  sequence  of  DBASE  II 
commands,  statement*,  and  control  structures  which  are 
organized  as  either  a  "command"  or  "format"  file,  ZIP  also 
places  any  embedded  execution  commands  into  the  file  and 
automatically  sees,  or  resets,  tne  appropriate  system 
"toggles"  as  needed. 

ZIP  is  a  useful  support  tool  for  DBASE  II  in  that  it 
relieves  the  user  from  having  to  program  a  "command"  file  in 
order  to  create  a  desired  display  format.  However,  it  must 
oe  pointed  out  that  ZIP  is  a  very  basic  formatter.  Is  line 
oriented,  and  is  incapable  of  the  more  complex  types  of 
displays. 


APPENDIX  X:  NAIL 


"MAIL"  Is  an  electronic  mail  facility  produced  by  tne 
University  of  California  at  Berkeley  and  Bell  Laboratories 
for  the  UNIX  operating  system.  It  allows  users  to  send 
messages  to  otner  users,  or  groups  of  users,  on  the  system. 

The  basic  unit  of  the  MAIL  system  is  the  message,  which 
is  simply  a  special  type  of  text  file.  The  message  is 
prefomatted  and  contains  fields  for  originator, 
destination,  subject,  copy  to,  and  body.  Messages  are 
contained  either  In  the  users  "private"  mailbox  or  in  the 
"system"  mailbox.  A  "dead-letter"  file  is  also  maintained 
for  each  user  to  contain  messages  which  cannot  be  delivered 
to  a  valid  destination.  The  private  mailbox  and  dead-letter 
file  are  maintained  as  text  files  in  tne  Unix  directory  and 
therefore  can  be  used  by  other  programs  running  under  Unix. 

Upon  logging  into  the  UNIX  system,  a  prompt  appears  at 
the  terminal  Indicating  that  there  is  mail  for  the  user. 
Messages  addressed  to  a  user  are  initially  contained  in  the 
system  mailbox,  and  can  be  read  from  the  system  mailbox  oy 
the  mail  facility.  The  messages  already  in  tne  private 
mailbox  and/or  dead-letter  file  are  text  files  ano  tnus  not 
directly  accessible  to  the  mail  facility. 

The  user  may  elect  to  read  the  mail  by  Invoking  tne  wail 
facility,  A  one  line  summary  of  all  messages  in  the  system 


mailbox  la  presented  to  the  user.  and  each  message  Is  given 
an  Integer  identification  number  starting  at  one.  At  this 
point  the  user  has  a  number  of  different  options  available 
as  summarized  in  Table  z.l. 


Table  1.1  •  MAIL  Command  Summary 


1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 
9. 
10 
11 
12 

13 

14 

15 

16 
17 
10 

19 

20 
21 
22 


23 

24 

25 

26 

27 

28 


Allas  a  name  4 
Unallas  a  name(s) 

Goto  previous  message  *  ♦ 

Goto  next  message  *  ♦ 

Display  summary  of  commands  ♦ 

Display  out  all  currently  defined  aliases 
Display  a  message 

Olsplay  out  headers  of  message  list  + 

Display  massage  list 

•  Display  size  of  each  message 

.  Display  top  few  lines  of  each  message 
.  Execute  the  following  Unix  shell  command 
.  Change  directory 
.  Delete  message(s)  + 

.  Delete  current  message,  print  next  messaae 
.  Undelete  messages  marked  for  deletion 

•  Reply  to  a  received  message  * 

.  Edit  a  list  of  messages  In  turn 
.  Send  message  to  designated  users  * 

•  End-of-message  ♦ 

.  Exit,  don't  change  system  mailbox  * 

.  Quit,  save  undeleted  or  unsaved  messages  In  the 
user's  mailbox,  save  unreferenced  in  the 
system  mailbox. 

•  Marx  message(s)  to  be  saved  In  system  mailbox  * 

,  Save  a  message  list  by  appending  to  a  text  file  * 

•  List  current  range  of  message  neaders 

•  Help  + 

•  Set  options  ♦ 

.  Unset  options 


*  RAIL  facility  has  more  than  one  command  to 
perform  this  action. 
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The  user  may  select  a  message  and  read  It,  After 

reviewing  the  message  the  user  may  forget  the  message#  save 

It  In  the  system  mailbox#  delete  it#  or  prepare  a  response. 

When  the  user  quits  the  mail  facility  all  messages  which 

have  not  been  deleted#  saved#  or  reviewed  are  placed  back 

Into  the  system  mailbox.  The  remaining  messaqes#  those 

reviewed  but  no  special  action  Indicated#  are  placed  in  the 

private  mailbox.  If  the  user  desires#  the  MAIL  facility  can 

be  exited  and  the  system  mailbox  left  uncnanqed. 

Additionally  the  user  can  create  "alias*  names  that 

correspond  to  multiple  users#  ask  for  message  summaries# 

append  messages  to  files#  or  invoke  an  editor. 

» 

The  WAIL  utility  does  not  contain  its  own  editor#  but 
depends  on  the  editor(s)  available  to  the  UNIX  system  and  on 
the  user  to  set  an  option  specifying  which  one  is  desired. 
When  the  user  indicates  that  a  message  is  to  be  created#  the 
editor  is  invoked,  the  user  enters  the  text,  and  when 
finished  Issues  an  end-of -message  command  to  return  control 
to  the  wail  facility,  while  in  the  editor#  tne  user  can 
issue  "escape"  commands  that  directly  effect  the  message 
processing.  A  listing  of  these  eseape  commands  is  provided 
in  Table  1,2,  Contents  of  other  files  may  be  Inserted  into 
the  message#  names  of  recipients  added  or  changed,  the 
header  field  edited#  or  an  alternate  editor  Invoked. 
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Table  1,2  -  MAIL  escape  commends 


1.  Execute  UNIX  shell  eoeeend 

2.  Add  neees  to  recipients  of  eopy 

3.  Reed  "deadletter”  file  into  message 

4.  Invoice  text  editor 

5.  Aoort  the  message  belno  sent 

6.  Insert  e  named  file  into  the  message  ♦ 

7.  Create  a  subject  field 

8.  write  tne  message  into  a  named  file 

9.  Pipe  the  messaqe  through  a  process  as  a  filter 

10.  Insert  a  string  into  the  message 


While  in  the  MAIL  facility,  UNIX  shell  commands  may  be 
Issued,  The  mail  facility  is  temporarily  interrupted,  trve 
command  is  executed,  and  then  the  mail  facility  Is  resumed 
without  adverse  effect. 


Table  1.3  -  MAIL  options. 


1,  (Append/Prepended)  messages  to  private  mailbox 

2,  (Yes/No)  Subject  line  prompt 

3,  (Yes/No)  Prompt  for  carbon  eopy  recipients  of  message 

4,  (Yes/No)  Modify  delete  command 

5,  (Yes/No)  Ignore  terminal  interrupt  signals 

6,  (Yes/No)  Include  sender  in  group  message  recipients 

7,  (Yes/No)  saving  Interrupted  messages 
ft,  Oeflne  default  editor  name 

9,  Oeflne  escape  character 

10,  Oeflne  file  to  record  outgoing  mail 

11,  Oeflne  number  of  lines  in  the  "top”  of  a  message 
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Additionally,  the  MAIL  facility  has  a  series  of  options 
the  user  can  change  to  tailor  its  operation.  Table  1.3 
provides  a  listing  of  these  options. 

The  MAIL  facility  Is  a  good  support  progra-  end  is  quite 
capable  of  accomplishing  Its  goals.  However,  It  has  more 
than  its  fair  share  of  problems. 

(1)  There  Is  a  very  limited  user  manual,  and  experience 
must  be  gained  from  other  users  or  by  trial  and  error. 

(2)  There  are  too  many  commands,  and  too  many  of  those 
duplicate  each  other.  The  number  of  commonly  useful 
commands  is  low  (marked  with  a  ♦  ),  with  the  rest  being 
wlndow-dresslnq. 

(3J  The  facility  Is  not  user  friendly.  The  user  must  oe 
aware  of  location  In  the  facility  and  what  is  exoected  next, 
because  there  are  no  special  prompts  and  the  help  command 
only  provides  a  command  summary. 

(4)  If  the  message  recipient  Is  on  line  when  the  message 
arrives,  wnatever  operation  Is  in  progress  Is  rudely 
interrupted  oy  the  display  of  the  message.  This  can  be  very 
disconcerting  to  the  redolent. 

(5)  The  user  can't  determine  which  message  is  aolnq 
where  (svstem  mailbox,  private  mailbox,  dead-letter  file), 
prior  to  leaving  the  mail  facility. 
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